Post Go back to editing

Boot Kernel modification for SPI master boot from different address

Hello,

    I am attempting to boot from another location other than 0x00 in Master SPI boot. I am following the instructions detailed in the Note EE-345 "Boot Kernel Customization and Firmware Upgradeability...." Much like the example in the note I have two applications both with boot kernels at addresses 0x000000 and 0x010000. The boot kernel at address 0x000000 has been modified to load the application at 0x010600. Essentially it does not work, I am not sure it typical debugging technics would be helpful here (ie using the catch line jump (pc,0) ). I inserted the SPI code shown in the note in my User_Init section. My gut feeling is that making these SPI changes is somehow tampering with the flow of program data to be loaded.

    I have attached my 369_spi.asm file for USer_Init section review. It follows very closely to the example. If I comment all of the SPI related code out, it will load the application at 0x000600 just fine. This confirms the PLL section is OK.

Thanks,

Glen

369_spi.asm.zip
Parents
  • 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.

Reply
  • 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.

Children
No Data