topic Re: RT595 boot over SPI timing & stability in i.MX RT Crossover MCUs

RT595 boot over SPI timing & stability

mwr — Sun, 13 Feb 2022 01:04:37 GMT

I'm trying to improve our boot timing by moving from UART to SPI boot. It's going well, at least 5 times faster at 20MHz compared to UART at 1M, but I'm running into some stability issues.

Using either spidev or a custom spi-backed serial interface with blhost, I frequently see it fail during boot with the following symptoms:

- the bootloader sometimes returns 5A twice in a row, in response to write-memory (instead of 5A, A1) often with a 3rd byte of A3, which I believe is data phase abort.

- this sometimes seems to happen if the host device tries to read the response byte(s) too fast, though it's hard to be precise about why it happens

- more commonly it seems to happen if the host device holds chip select down for too long on a write-memory data transfer. it seems that if that happens, or for whatever reason it is too slow to read the response, then it will trigger an abort.

I don't think I can diagnose this further without source code or detailed specs for the bootloader. So I'll just ask some questions:

1) Is boot loader source available?

2) Are there any specs on the timing requirements, particularly around chip select, time b/w writing and reading, between subsequent reads, etc?

3) I've see this work at 50MHz, though I'm testing it at 20M. The reference manual claims the default is 2M in one place, then 24M in another, but it can be higher if the device is running in "high speed" boot mode. What is the definition of high speed boot mode - I can't find any information about it.

4) What are the reasons the bootloader can respond with A3 after write-memory?

I've also tried nIRQ mode btw, so far I'm only observing the interrupt line toggle to see the timing and aren't actually driving the host from it. My suspicion is that even if I did that, the timing would still be violated.

I should add that this works reliably when the system is fairly idle, but we can have some fairly chaotic system load and timing just after boot which can distort, stretch, and randomly delay the spi bus.

I would very much appreciate any input or sources of more information on this subject,

~Mark

Re: RT595 boot over SPI timing & stability

Omar_Anguiano — Sat, 19 Feb 2022 02:25:17 GMT

Hello
Hope you are well, I will gladly answer your questions:

1) Unfortunately, we don´t have the source code available.

2)The timing required for SPI are the ones specified at chapter 1.7.5. I suggest you make sure that #CE remains unasserted during idle state.

3)You can find more detailed information at the OTP fuse map attached in the Reference Manual. BOOT_CFG[0]:bit7==1 set the high speed boot:

4) This could be caused by the baudrate. If you are in Normal boot you could try a different baudrate or set high-speed boot for higher baudrate in SPI.

If you have more questions do not hesitate to ask me.
Best regards,
Omar

Re: RT595 boot over SPI timing & stability

mwr — Thu, 24 Feb 2022 21:29:47 GMT

Thanks Omar!

Here's a bit more information on the failure mode in case you know why it happens/how to deal with it.

When it works the sequence is:

-> write-memory

<- 5A

<- A1

-> write-memory

etc

But when it fails we see this:

-> write-memory

<- 5A

<- A1

<- FF

<- FF forever. It keeps trying to read one byte and never gets a response, which I think SPI sees as FF.

The timing looks the same b/w success and failure cases. We are using an old version of blhost (2.6.2), so we'll update that. Do you know if returning 5A multiple times is a fatal error or perhaps blhost should accept it?

I've attached a diagram to show the sequence. The clock here is 16.7MHz

Re: RT595 boot over SPI timing & stability

mwr — Thu, 24 Feb 2022 22:19:32 GMT

There's another failure mode too, where it returns A3 (data phase abort). I think this happens if the timing from the host is abnormally slow, but we want that to work, because the system is heavily loaded and some slowness should be tolerated if possible. Perhaps the timing is unnecessarily strict. Boot over UART seems much more tolerant, and works even with extremely staggered clock, etc.

Re: RT595 boot over SPI timing & stability

Frank_Kim — Wed, 09 Mar 2022 01:15:17 GMT

Hi Mark,

As Omar replied, we don't have blhost codes to use GPIO for SPI timing. Instead, we can provide tech support to give you an idea where you can put GPIO in the source codes for testing.

I tested SPI interface with blhost 2.6.7. (attached here). It is original blhost codes. I ported it onto RT600 for testing SPI communication with GPIO. All those changes are meaningless to you. The changes that I made necessary for GPIO check is Serialpacketizer.cpp. Please refer to the codes and positions of WAIT_GPIO(x). You may also find some other changes in the file compared to the original. But you can ignore them because I made other changes for RT600 test only. Hope that it will be very clear to you. If you have any questions, please let us know.

The g_setProperty_Flag is used for the first set_property command. Set_property command will be initial command to notify the ROM of GPIO port and pin name to be used for timing. Once this command packet is sent to RT500, RT500 initializes GPIO for purpose which will drive to high. If 5a and a1 are ready, it will drive back to low for indication to the host. The host needs to check that low and then read out.

- original blhost 2.6.7.zip.

- SerialPacketizer.zip which contain GPIO check.

- MIMXRT685S_Project.zip which is main file for testing. It shows g_setProperty_Flag. The purpose is to set it when set property command is issued.

Regards,

Frank