set the channel description: This channel is for discussion and support of bring-up and testing of silicon for the version of Caravel on ChipIgnite 2204 and later, and on open MPW-6 and later.

Hi @Tim Edwards and everyone, For a while we were able to get meaningful reads from the chip’s ID registers and write the blink program to the flash memory. However on two of our chips, and we experience this on two evaluation boards, we are now getting this readback:

❯ make flash
python3 ../util/caravel_hkflash.py blink.hex
Success: Found one matching FTDI device at <ftdi://ftdi:232>h:14:c/1

Caravel data:
   mfg        = ffff
   product    = ff
   project ID = ffffffff
make: *** [flash] Error 2

We can monitor the MEM SPI bus on a logic analyser and see that there are memory read requests, and the program being read is quite similar to the one we flashed. On the USB SPI bus, we see that the USB_SI line is always high, which is interpreted as 0xff. We tried running the flashing program with the reset button held down with no effect. We tried measuring the voltages. 3V3 is as expected. 1v8 reads 1.59V, and the voltage regulator on the evaluation board is a 1V6 one. Is that expected? Would that have an effect on things? Another observation: when we plug in the evaluation board to power, we see that the GPIO line is almost always high. It is pulled low for nanoseconds at a time sporadically. The LED is always on. Activity on the memory bus comes in bursts, and it is only during these bursts that the GPIO line is goes low. The memory it asks for are at

0x000000
0x0000a0
0x000900
0x0000e0
0x000904
0x000100
0x000740
0x0003c0
0x000340
0x0003a0

0x000360
0x000220

# delay

0x0002a0
0x000360
0x000220

# delay

subr:
0x0002a0
0x000380
0x000360
0x000220

# delay 

0x0002a0
0x0002a0
0x000360
0x000220

# jmp: subr

After about 0.8s, we see a change in behaviour. There is constant activity on the memory bus and the GPIO line oscillates between 1 and 0 with frequency 598 Hz and the LED is always on. The memory locations being streamed are from 0x2a0, then [0x860, 0x220, 0x880, 0x220, 0x8a0] repeatedly. Could you give us some pointers as to where something might be wrong? Or some next steps in debugging? We attach also the

blink.hex

and

blink.lst

that we are using. Thanks for your help.

@Gabriel Gallardo: Just a quick response to the first part of your question. I have a meeting in a couple of minutes but afterward I'll look at the rest of your post and respond. Note that the host computer talks to caravel through the FTDI chip by talking to the SPI on pins 1-4. If you run a program on the flash which changes the function of pins 1-4, then you lose access to the chip because the GPIOs will change state soon after the chip powers up or comes out of reset. The solution to this is to hold down the reset button on the board and then power cycle the chip (by unplugging and re-plugging the USB cable) while you still have the reset button pressed. Keep the reset button held down while you start the flashing. Once the flash is erasing, you can release the button; the first part of the flashing program is to put the chip into reset through the SPI interface and hold it in reset. Both the reset and power cycle are needed. Which is why, generally, it works better to write programs that maintain the default state of GPIOs 1 to 4, so that you don't have to do the complicated reset + power cycle thing every time.

Thanks for the quick reply. That worked for us. Quite curiously, we hadn’t reprogrammed pins 1-4. On Friday I tinkered with the LED delay and reflashed and it was fine. I went away for lunch and found our chip unresponsive, in the state I mentioned above.

@Gabriel Gallardo: Figuring out what data are supposed to be going back and forth to the SPI is tricky, because the VexRISC does have a tiny instruction cache, and will read a handful of addresses in a burst, aligned to some boundary like 4 or 8 bytes and not necessarily at the jump address, and if a loop is very small it might fit into the instruction cache and you'll see nothing accessing the SPI flash for a period of time. As for the startup:

blink.c

starts with a GPIO programming stage which takes rather long because it is bit-banging the whole serial programming chain. That's followed by a message output at the leisurely rate of 9600 baud until it settles into the blink mode. But the blink mode is supposed to be several Hz, not several hundred Hz. At several hundred Hz you get an LED that blinks faster than your eye can track, so you just see that the LED is on. FYI: After testing a number of chips, we decided that the best yield of working parts occurred at an internal digital power supply voltage of about 1.6V, so we dropped the LDO output on the boards slightly, which is why you don't see 1.8V.

Thanks for the insight, Tim!

Just a further observation, on one of our chips, within O(seconds) or O(minutes) of flashing it, I would try to query the Caravel ID registers and get garbage. We saw that if we halved the speed of the HKSPI 12MHz → 6MHz, the problem went away. Lowering the HKSPI bus speed brings it closer to the 2.5MHz of the SPI flash bus speed.

In the response to the request for what's different between the older version of Caravel (used on MPW-2 to MPW-5, and ChipIgnite through 2110C inclusive), here's a summary: • Old Caravel: Has hold violations between the GPIO configuration blocks and requires running a calibration script to determine where the violations are and compensate the configuration accordingly. Some configurations may not be possible, in which case an alternative configuration like a weak pull-up or weak pull-down state may be necessary. The calibration requires detecting values at the pins which cannot be done simultaneously with setting the value at the pin due to the 1-wire communication to each GPIO, so the Nucleo board has been added to the development board system mainly for the purpose of running one side of the calibration. When running a program, you need to include the configuration vectors produced by the calibration and run a subroutine that bit-bangs the configuration to the GPIOs. • New Caravel: No hold violations. When running a program, you just need to specify the configuration for each GPIO and then trigger the serial transfer. • Old Caravel: One-wire communication from the management SoC to each GPIO. Each GPIO can be configured for use by the management SoC as an input or an output, but not both at the same time. The managment SoC can monitor user project output or provide stimulus to the user project, but the setup is rather complicated. • New Caravel: Two-wire communication from the management SoC to each GPIO. Each GPIO can be configured to read and write simultaneously, which makes it easy to set up modes where the management SoC monitors the user project output or provides stimulus to the user project. • Old Caravel: An error in the memory map prevents many housekeeping functions from being accessed from the management SoC. • New Caravel: The entire memory map is accessible from both the management SoC and the housekeeping SPI, including all housekeeping registers. • Old Caravel: The housekeeping SPI had hold violations and certain housekeeping register bits could not be set. For example, the DLL can be turned on in DCO (free-running) mode, but not in DLL (locked) mode. • New Caravel: All housekeeping SPI registers are fully accessible and the DLL has been completely tested and verified. If I think of more items, I'll add to this list.

Silly question… when we taped out we used the lowest 8 GPIO pins for an output, of those we need only the lowest 3 to get a useful value (either

0x4

or

0x3

). Do I understand correctly that pins 1-4 are used for the HKSPI? What would happen if I tried to configure them for our output? and how could I go about doing that?