I did some preliminary bring-up on the D7 slot (Tr...
# mpw-3-silicon
h
I did some preliminary bring-up on the D7 slot (TreePRAM). The first two chips I tested failed the characterization of the low IO chain and either failed or passed the high IO chain depending on voltage and the chip being tested. 1.5V seemed the most stable. The third chip passed the characterization of both IO chains at 1.55V or below. It also passed the sanity check and the gpio_test firmware. My project has some debug facilities where I can write data to the logic analyzer pins and read it back through the gpio's and that also works. There were no major issues along the way, but there were many "paper cuts" - small issues with the potential to turn into time sinks. - The onboarding instructions mention putting two jumpers on J8 & J9. I was wondering whether I missed some jumpers in the box or if I should remove them from the nucleo board (the ones on the bottom side seem safe to remove) or if I am expected to have them lying around. I wanted to play safe and scoured my electronics box for a pack of jumpers. Same for usb cables: the instructions call for two of them while there is only one in the box. I definitely have many usb cables, but Matt's bring-up video has this warning about the quality of them which is not so easy to check and not something you want to risk in an environment with so many uncertainties. - Early on in the bring-up process you come across the notion of independent and dependent hold violations. I wanted to understand what they mean, but googling it wasn't particularly helpful and neither was the search function of the slack workspace. So I went into the rabbit hole of reading
io_config.py
and ended up in a code block stitching together hardcoded riscv bytecode fragments based on whether the particular pin is
H_INDEPENDENT
or
H_DEPENDENT
. Eventually I found some info in the MPW-2 errata, but more would be definitely welcome. - Two of the pre-assembled m.2 boards were marked as "pass". So I tried them first and they were the ones that failed the characterization of the IO chains. A third one that didn't have the marking passed the test. I wonder what the "pass" marking means. - Once you get to gpio_test you need a riscv cross-compiling toolchain. There is one in my distro's (opensuse) package manager but it doesn't seem to work with caravel. So I tried to build a riscv toolchain from source and got some compilation errors. Instead of digging deeper I settled with the prebuilt version at https://github.com/stnolting/riscv-gcc-prebuilt which does the job quite well. - Each firmware subfolder has its own copy of gpio_config_def.py. I've spent more time than I'm willing to admit trying to figure out why my project doesn't work when that particular copy of gpio_config_def.py was out of date. Changing them to symlinks made it easier.