I'm just getting around to testing my MPW3 chip now. So if I understand correctly even if the gpio configuration passes, you aren't guaranteed to have working GPIO right? It is just determined by how many dependent/independent hold violations you have in a row? I am only getting io[37] working which makes sense given the hold violations. So I just need to keep testing chips until I get ones that has a good "pattern" of hold violations such that it can be accommodated for?

does the gpio config tool "pass" as in it completes, or does it say that the entire chain is passing?

passes as in it says the entire chain is passing

oh interesting

Yeah that makes sense

but theoretically (and for most of my tests) it seemed that if gpio config passed consistently, then actually configuring those gpio settings generally worked fine (after copying over the python file of dependent/independent violations produced by the gpio config)

Ok, thanks for the help. I'll try just turning down the voltage

interesting

Yes io37 is what I expect

i see

I need to take a look at io0 again, I think I was seeing a square wave but not logic level?

oh possibly yeah

make sanity check works consistently

wait the first one is H_NONE?

that makes sense right?

oh wait yeah

gpio_config_data.c

interesting, i get something else when i run make with your gpio_config_def.py

sorry i sent you an outdated one

ah alright

does sanity check use the data.c from gpio_test dir or nucleo dir?

from the gpio_test dir

I noticed sanity check print H_INDEPENDENT on every line regardless of what is in the def file

i had that too, i believe that's a just bug in the printing code

ah ok

that... is really strange though

i've tried some other dies but not at 1.45v so maybe i'll do that

it would be interesting to see if you find any dies where io[36] is INDEPENDENT

thanks for the help, i'll let you know what i find

that's... incredibly weird

I did notice that my make check was failing on my initial tests on the chip I was testing last night though...

if you disable io37 in your config then does it stop working? that would prove whether the config is being loaded at all or not

I disabled all the low gpio pins and that fixed the make check though

is it possible the firmware on the nucleo board is mangled? or is it the latest copy of the micropython code from the repo

I just reflashed it today. I'm on 1.2.2

if somehow the nucleo board was driving the pins while the caravel was also driving them

Maybe it could be my cross compiler?

that could cause that? the drive strength on the caravel is weak so you wouldn't notice if there was a driver conflict

I build from source

interesting

I grabbed the multilib

I wonder if you weakly drive the io36 externally (3.3v thru a 5k resistor) whether that would reveal anything (i.e. whether the pin is being actively driven low vs just floating)

I can try that but i suspect it is floating just from the slight wiggle i see on it compared to io37 with my scope

a slight wiggle (at the same frequency) would be consistent with a weak driver fighting with a strong driver i think? or it could just be crosstalk from io37

I'll need to test this later, I don't have the equipment on hand

that almost looks like the high side is just left floating but the low side is driven

when the sanity check is running I see it get driven to logic levels, but I don't that happen when I just power on the board with gpio_test

do you know what bit config sanity check uses for the ios

I think it copies the def.py to the board and then generates it on the board itself

weird

Thanks for all the help I think I've taken enough of your time, I'll let you know if I ever figure this out

To return to your original statement:

"So if I understand correctly even if the gpio configuration passes, you aren't guaranteed to have working GPIO right? It is just determined by how many dependent/independent hold violations you have in a row? I am only getting io[37] working which makes sense given the hold violations. So I just need to keep testing chips until I get ones that has a good "pattern" of hold violations such that it can be accommodated for?"

If you can pass configuration, then no, it's not absolutely guaranteed that you can have a working GPIO for your user project, but most of the time (95% of cases, maybe?) you can get the functionality you need for the user project, although sometimes it takes a bit of clever thinking about it. If you have too many dependent hold violations on a particular chip, then that chip becomes effectively unusable if you're trying to reach any GPIO toward the middle of the range. The first thing to do is to summarize what you have seen so far. (1) Do you have chips for which the GPIO calibration completes and passes? (2) Are you able to run a simple toggle test from management, configuring the GPIO according to the results of the calibration, and confirming that all I/O are toggling? (3) What is the target configuration for your user project? How many channels are you using, and which ones are inputs and which are outputs? (4) Have you run the I/O simulation script to confirm that your settings for the user project are valid?

Thanks for the reply! 1. I have a chip that consistently completes (passes all GPIO) calibration at 1.45 volts and passes the sanity check, however there are 10 dependent hold violations on the start of the low gpio side. 2. When I run the gpio_test toggle test I can only see io[37] toggling but nothing else. It seems like other pins can get pulled down to ground but don't get driven high. I have the correct gpio_config_def.py in the directory. 3. I haven't even tried to run my own code since I wasn't able to get the toggle test working. The minimum gpio I need is just io 14, 16, 23 which need to all be grounded, and then hopefully one other gpio (maybe 37) to bitbang some data out. Maybe this will just work with what I have now since it seems like I might be able to drive arbitrary gpio low. If I can get more gpio working there are more tests I can run. 4. What is the I/O simulation script? Is this different from 'make check'

The behavior reported in (2) there is not expected. If you can pass GPIO calibration then you should be able to see all the I/Os toggling (in the worst case, you might get intermittent behavior somewhere in the middle of the I/Os; That's when I go looking for another chip to test). This sounds like a failure to get the calibrated result compiled into the toggle test. If you can zip up your files and post them, I can take a look at what you're doing. I do have an alternative calibration method that is much faster and much simpler than the published one which you might want to try (I will have to dig it up and refresh my own memory on how to run it). The simulation script is

caravel_board/firmware/mpw2-5/gpio_config/gpio_config_simulator.py

. It is not directly accessible from a

make

target.

Ok I ran the simulator and I see 1000000000011 for every GPIO that is set to MGMT output and all 0s for the disabled ones. Is https://caravel-harness.readthedocs.io/en/latest/gpio.html this information relevant for MPW3, because that would seem to imply my output is disabled? Here is the firmware I am testing with. I'm was just trying to toggle the high gpio with the low gpio disabled.

Give me a ping tomorrow so I don't forget about this, because I don't have time to look into it tonight.

@Jesse Cirimelli-Low confusingly enough, the "gpio" refers to the single gpio pin connected directly to the mgmt and just labelled as gpio

@Jesse Cirimelli-Low: Your "simulator_output" shows every channel from 19 to 37 set to management output (correct for the toggle test), but nothing is being set for channels 0 to 18. . . Only zeros are going in. If the simulation reflects reality, then you should see toggling on GPIO 19 to 37 but not on GPIO 0 to 18 (which as I understand is not what you're seeing).

I've tried with gpio_config_io comment and uncommented without seeing any change. What should reg_mprj_xfer look like for MPW3?

It shouldn't matter because the program bypasses the registers and uses a bit-bang method, so the register values will stay put.

@Tim Edwards @Anish Thanks for all the help. Commenting out the reg_mprj_xfer got all the gpio working 👍