Boot Kernel modification for SPI master boot from different address

Hi Glen,

     I went through the  example code you have posted. I could see that the main difference between the example code with the EE-345 and your code are as follows:

1. Speed is different.

2. Wait for SPI DMA uses some LEDs to check the state. 

WAIT_FOR_SPI_DMA:
    SRU(HIGH, DAI_PB16_I);               // Debug LED, turn on   
    ustat1=dm(SPIDMAC);         // Waiting for the DMA to finish
    bit tst ustat1 SPIDMAS;     // Check SPI DMA Status bit
    SRU(LOW, DAI_PB16_I);               // Debug LED, turn on 
    IF TF jump WAIT_FOR_SPI_DMA;// SPIDMAS = 1 when DMA in progress

Will it be possible for you to move the "SRU(LOW, DAI_PB16_I);" macro call after the If condition check. In case the SRU macro uses some conditional code then the SPI condition might not be same when the condition is tested. If possible, I would also suggest you to test the example code as it is on your board.

Best Regards,

Jeyanthi

It seems as though I cannot make any changes to anything SPI related. Or else it would corrupt the default SPI setup for the transmission of the program code. For example, if I do nothing else SPI and only do the first two lines of the example code (r0 = 0x80; dm(SPIDMAC) = r0;) then no program will load. However, if I save and restore the original value of the SPIDMAC register, then my program loads fine. So its seems that maybe if I backup and restore each of the altered SPI registers it might work. I have yet to complete this. However, this seems like an awful big step to leave out of the engineering note. This is why I feel as though I am missing something altogether. But I do not see what it could be.

No, it won't work. The next two line of the provided example code (btw this code is on page 5 of the EE-345 document) are to flush the RX and TX buffers via the SPICTL register. Once these buffers are flushed, program code will not boot. I even tried saving the RXSPI, TXSPI and SPICTL registers, flushing via the SPICTL register and then immediately restoring all three. This still did not allow the program code to be uploaded. No idea...

All set now. Had to bust out the scope and watch the SPI lines.Turns out my PLL was not latching properly. I could see the entire boot kernel go by at one clock frequency, then a slight pause and a change in frequency for about 11 bits corresponding to the running of the kernel and my change to the PLL, but then after about 11 bits it changes back to the original frequency. This slight distortion in the SPI clock must have corrupted the stream.

  The solution (for now anyway) is to not set the PLL and not change the SPI clock divider. I just let the defaults do their thing and it works A.O.K. I had no problem loading a program from another sector.