The SPI master boot fails on BF518 custom board when running at higher clock rate (above 5MHz). Everything is fine at lower clock rate. The code is mapped to SDRAM (MT48H8M16LF-75) and the intialization is all fine. Any suggestions?
The result of this investigation was that the application had the correct timing to arrive at scenario 1 in the anomaly description for 05-00-0490. The large block size broke the work unit up over multiple DMA blocks, which allowed a portion of boot ROM code to run that otherwise doesn't run, and it was this code that was sensitive to the unique timing required. When the workaround was employed, the failure no longer occurred.
the SPI boot is supposed to be run up to system clock / 4. I could prove this on our evaluation boards.
What SPI memory part are you using? Can it run up that speed?
Have you taken the init code examples from VisualDSP++? There are some things to be done by the boot rom when increasing the spi clock during the booting process.
Thanks for your reply Andreas..!
I'm using the init code provided with VDSP. The changes I've made is wrt CLKIN, VCO, CCLK, SCLK. My configuration sets CCLK and SCLK to 198MHz and 66MHz respectively. To set the desired SPI Baud rate, I'm changing the SPI_BAUD_VAL defined in the ezboardBF518f_initcode.h
With these settings, I'm able to successfully boot at lower SPI clock rate and thus proves SDRAM settings are fine. However, things fail at higher SPI clock rate. The SPI device used is M25P64.
Do you think anything missed out in the config. Let me know your suggestions.
I agree with Andreas. This does appear to possibly be a hardware problem. Although the front page of the M25P64 datasheet does claim 75MHz operation the fine print looks more like a maximum of 20 MHz for reads. There are also some setup and hold time considerations that could make things slower.
Are there other devices on your SPI bus that might add loading or cause the trace lengths to be long?
people are probably confusing slow and fast spi reads. the slow reads often top out at 10-20 mhz while the fast spi reads top out at the same rate as everything else in the device. you cannot use the slow read opcode with a M25P64 at speeds higher than 20mhz just like the datasheet says.
as you are using the init code examples and just adjust SPI_BAUD_VAL, it should work from the software perspective.
I had some customer boards in the past where booting from SPI memory caused some trouble at high speeds. This is usually a hardware issue.
Can you provide aus an extract of the schematics? Are all required pull-up/down resistors applied?
I'd like to provide some details on this issue:
The boot process stops always at the same position in the loader file. The cause is a block header checksum error in the ROM bootloader. I've debugged the bootloader. The buffer "ldf_header_space" normally holding the header of the currently processed LDR block is corrupt. The usual layout in the buffer matches the layout of the block header structure. In failure state the buffer holds the value 0x00000098 on the first two uint32 locations. The two trailing uint32's are holding the block code and the target address which should be at the first two locations. This happens after a successful transfer of 0x1D34C bytes to the SDRAM bank 1 of a 16MByte SDRAM. Dumping the SDRAM content and comparing it with the loader file shows valid data up to where the boot stream is interrupted. Tracing the SPI interface with an oscilloscope shows that the boot loader addresses the right location in the SPI flash. However the data transfer stops after 13 bytes and after only seven cycles of SPI clock inside the thirteenth byte. The data transferred on the MISO line so far is valid. The same loader file boots without problem with SPI clock rate equal to or lower than 4.7MHz.
Hope this helps finding an answer.
Sorry for the delay. Your last post made it sound like it always failed the same place. If this is true for different temperatures, different data patterns and different memory chips, it is not likely the hardware timing problem that I suspected.
At this stage, I believe this issue will require some debugging and analysis of your code, and would therefore be better handled by the private support channel. Please use the Support Form (link below), to contact us. Please also include a link to this forum discussion. http://www.analog.com/processors/support. If appropriate, the outcome will be posted here.
can you dump the content of the Boot ROMs pLogBuffer at address 0xFFB04000 after the booting process stops?
Each content of the log file consists of 8 32-bit entries per ldr block that is processed:
• The block code word (dBlockCode) of the block header• The target address (pTargetAddress) of the block header• The byte count (dByteCount) of the block header• The argument word (dArgument) of the block header• The source pointer (pSource) of the boot stream• The block count (dBlockCount)• An internal copy of the dBlockCode word OR’ed with dFlags• The content of the SEQSTAT register
When you load the ldr file into the ldrviewer ( http://www.dolomitics.com/downloads/ldrviewer.html ) you can compare the log against it.
thank you BobK and Andreas for answering.
The issue is known by the support forum right from the start of this thread. The initial post has been made by the Support Forum ( kprasad82 ).
For now a solution to the problem seems to be a "-maxblocksize 0x8000" option to the elfloader. With this I am able to boot with full speed from SPI flash.
With regard to your question about the problem showing the same symptoms:
With another loader file the ROM bootloader completed the load successfully. However the application didn't start. A dump of the SDRAM showed missing bytes. Despite the missing bytes the ROM bootloader was apparently able to resynchronize with the next block in the loader file and completed the load process. I think the checksum error described in my previous post is just another result caused by the real problem.
I've sent a hardware and my complete project to ADI for diagnosis. I'll let you know if anything other than the elfloader option comes out of it.
I would suggest that we close the discussion here, because...
... I will have access to your hardware and try to assist with to debug the issue.
I have a problem that is similar to this one: after boot from SPI some bytes in the SDRAM are wrog.
Would you mind writing here the solution for this problem (if it has been already found...), please?
Retrieving data ...