https://open-source-silicon.dev logo
Join Slack
Powered by
GPIO from the management core works fine for me, b...
# mpw-2-silicon
m
GPIO from the management core works fine for me, but output from the user space doesn't seem to. I basically have a scan chain 112 bits long with the scan in, clk, enable coming from GPIO and the output going to GPIO and I can't get anything to scan through it. I'll have to check the reliability of the GIO configuration, maybe?
Is there a way to adjust the LDO from C firmware?
g
How fast are you running the IO? Inputs are fine at any speed but with the default setup outputs will be in a weak pull-down (iirc) mode that are fast to rise but slow to fall.
in general, it's easiest to get fast outputs if they're surrounded by inputs
t
@Matthew Guthaus: If you're looking to set the voltage, it needs to be done through the Nucleo by passing a voltage to the 
powerup_sequence()
routine. For the configuration, please post some code and I can check it to see if the configuration is valid. As @gatecat mentions, if you are trying to run more than about 1MHz, then the default output type, which has a slow fall time, may fail to reach a low logic value. Otherwise, it's probably a configuration issue.
m
@gatecat 100Hz
Can I run micropython to change these settings and then run my firware? I thought I need the micropython firmware to do these things? Maybe I'm conceptually missing something.
g
The pin configuration itself is ultimately done by the C code running on the caravel. The micropython code is responsible for programming that into the flash, and in combination with the caravel, working out what the hold failures in the IO chain are by testing various IO configurations.
m
I'm also not using the default pin setup. I have my own setup.
It's using the gpio_config_def.py with my custom timing.
The micropython is running on the nucleo board and not the caravel chip?
t
Yes, the micropython is running on Nucleo, not caravel.
j
@Matthew Guthaus can we get on a call to quickly over what you are trying to do?
m
@jeffdi Yes
Ok, but when I flash_nucleo, that overwrites the micropython firmware, correct?
j
t
@Matthew Guthaus: Check the post from yesterday from @Yatharth Agarwal with the flowchart of how the system works. . . It's a very nice illustration.
🙌 1
@jeffdi: There are definitely some problematic issues with 
gpio_config_builder.py
for user configuration. The key is to maximize the shortest run of zeros in the entire configuration. You will only be able to get a run of zeros of length N past (N - 1) dependent hold violations. Any more than that, the number of extra 1s that have to be added collides with the neighboring configuration word. The current definition for C_USER_* bit configurations includes things like 
0110000000010
for C_USER_OUT. Put two of those in neighboring channels, and your shortest run of zeros is two, meaning that you can get that configuration only through one dependent hold violation before it stops working. Fortunately, since the user side interface is a three-pin bidirectional inteface, most of the configuration word doesn't even affect how the user project generates or accesses data. The only exceptions are the management enable bit (must be 
0
for any user mode), and the 3-bit output mode. I would advise that 
C_USER_IN_NP
be set to 
0010000000000
and 
C_USER_OUT
be set to 
0110000000000
. User weak pull-up and weak pull-down input modes can be left as-is (but require that the user has understood that these modes require driving the output, which they will need to have done appropriately in their design). The abovementioned definitions will survive through a series of nine dependent hold violations. The output mode will have a weak pull-down, and users who need a >1MHz output should get in touch with us on how to arrange the configuration to make that happen.
Open in Slack
PreviousNext
Powered by