@Matt Venn @Tim Edwards Is there is any change in Caravel flashing scripts for CI2306Q chips? Bring-up setup used in CI2206Q is not working here. Caravel Bring-up board Rev-5A looks to be same between CI2206Q & CI2306Q.

2304 parts work; I don't think I've had any 2306 parts to test. If you remove the caravel chip M.2 card, I assume you can see the SPI clock being driven by the FTDI chip along with the other two signals? Is this repeatable over multiple chips?

I have tested in four M.2 card and all are showing same issue. I can see the SPI clock, when i remove the M.2 Card. If I program the flash with my CI2206 chip and then replace it with CI2306, I can see GPIO toggle is working, which mean CI2306 chip boot is working; problem is with flashing the device. I feel like it's packaging issue, Is any reported successful flash of caravel CI2306 chips ? Is there is separate channel where chipignite silicon status are discussed?

The #mpw-6plus-silicon channels was meant for silicon tests of anything with the most recent Caravel design, which includes all of the ChipIgnite runs except the first one.

I'm waiting on 2306 chips - should arrive tomorrow

There is definitely an issue with the 2306 chips in which the GPIO defaults did not get programmed. It will power up with all GPIOs completely disabled. Each board should ship with a valid "blink" program on it which should switch the GPIOs into a working state immediately after startup. That, however, doesn't exactly match what you're seeing. If you put a working C program onto the flash and it configured the GPIO in a way that keeps the housekeeping working with the CI2206 chip, then it ought to be working with CI2306. If the C program didn't specifically set channels 1-4, then that would cause an issue. But with the defaults being off/disabled, there shouldn't be any way for GPIO 2 to be a grounded output, which is what you're observing. So I don't think I've figured out the full story going on here. Can you post the C program (or just the GPIO setup part of it) that worked on the 2206 part but not the 2306 part?

@Tim Edwards GPIO defaults worked fine on my 2306 parts...

@Anish: Which design was that? Was that new for the 2306 run or a respin of an earlier design?

new for 2306

Thanks; I have the slot number and can take a look at what got sent to the foundry.

@Dinesh A I think I had to hold down the reset button while plugging in the dev board USB and until I ran the flash command, in order to avoid the blink code from hijacking the I/Os. But I'm not 100% sure since I didn't look too closely (I was already in the habit of doing this whenever anything failed)

@Anish: I just confirmed that your chip is fine; the problem must have been introduced in the middle of the tapeout and I don't know what fraction of the designs were affected. Yours was not. Dinesh's was.

huh, strange, okay

Looks like the 2306 designs were processed in two batches, one on June 6 and the other on June 9. My conjecture is that one of those batches has the error and the other doesn't, although I will have to stare at a number of layouts to confirm that.

To be clear @Tim Edwards, ignoring the batches, you have confirmed that Dinesh's GPIO defaults are definitely affected? But as I understand this also doesn't necessarily explain the apparent stuck SCK? @Dinesh A, just to check, could it be something as simple as a manufacturing defect affecting all your M.2 cards? I wonder what SCK and CSB look like on an oscilloscope (since they're right next to each other on the QFN package, from what I understand).

I have done couple of experiment 1. I don't see any connectivity shot between SCK (IO[4]) with rest of the pins and power + ground 2. I have standalone development board with M.2 card plug-in option without FDTI SPI chip. With power-up condition + Pull-up on SCK (IO[4]) pin; In 2206 Chip, SCK pad goes high, where as 2306 Chip shows low. It looks like there is a active output driver in 2306 driving it low. 3. Holding the Reset does not change the behavior of SCK pad It's appear like SCK pin Default GPIO configured in output or bi-direction mode with oen configured as output My caravel boot up script which works in 2206 and fails in 2306 available at: https://github.com/dineshannayya/riscduino_examples/blob/main/bootloader/cache_dis/hello_world.c With pre-programmed caravel flash, i am able to access my project.

@Dinesh A do you mean 2306 is able to run this firmware from the flash, so long as the flash was already programmed (using the 2206 chip, as you explained earlier)? If that's the case, that would mean the 2306 chip is at least correctly driving SCK (IO[4]) for doing XIP... and the main problem you're observing is that it doesn't correctly behave as an input for programming and housekeeping?

@Andrea Vedanayagam I am using 2206 chip to pre-program the caravel flash in the board and then replacing it with 2306. Caravel booting uses flash IO interface and it will not use SCK pin.

@Anton Maurovic: Yes, I did confirm that Dinesh's chip has the issue, as do just about everybody else's projects. I think we pinned down that part of it as being related to the time of submission. Apparently Anish got his submission in early.

Cheers Tim. My apologies @Dinesh A I think I was mixing up

SCK

and

flash_clk

@Dinesh A: The issue with SCK might be as simple as this: In your C code, you have:

reg_mprj_io_1 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_2 = GPIO_MODE_USER_STD_BIDIRECTIONAL;
    reg_mprj_io_3 = GPIO_MODE_USER_STD_BIDIRECTIONAL;
    reg_mprj_io_4 = GPIO_MODE_USER_STD_BIDIRECTIONAL;

You have made pins 2 to 4 a user mode, so they are set to whatever the user project is doing, which could be either input or output. I suggest that for any tests where you don't need to access GPIO 2 to 4 from the user project, you use:

reg_mprj_io_1 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_2 = GPIO_MODE_MGMT_STD_INPUT_NOPULL;
    reg_mprj_io_3 = GPIO_MODE_MGMT_STD_INPUT_NOPULL;
    reg_mprj_io_4 = GPIO_MODE_MGMT_STD_INPUT_NOPULL;

However, if you need to look at user project I/O on GPIO 2 to 4, then you will lose the ability to program through the housekeeping SPI and you will have to resort to either programming through the older 2204 part, or jumpering the header pins to program the SPI flash directly from the FTDI part, bypassing the Caravel chip.

@Tim Edwards I was not suspecting the caravel default configuration as it's was well defined flow from MPW5/6 on-wards. Thanks for quick follow-up 🙏 and tracing out the real reason for the CI2306 flashing issue + different workaround option.

I thought of another useful workaround that would allow you to have user access to GPIOs 1 to 4, which is to change the management GPIO (the one driving the LED) to an input, and then run a program on the management SoC that will detect a change in the management gpio input, and configure the GPIOs for user project access when it goes high, and configure them for management access and housekeeping SPI use when low. Then, all you need to do is to jumper the "gpio" header pin to 3.3V to run your user project tests, and then ground it to be able to re-program the SPI flash.