K64 Custom Bootloader

[kyati]

Hi All,

I am revisiting a bootloader built with KDS and KSDK 1.3 and processor expert, loading image files from an SD card to reprogram a custom K64 board. I am continuing a discussion from K64 Bootloader Pre-jump Checklist , where I had unresolved issues with what seemed like interference from the bootloader and application images. I needed to memset the SRAM blocks in order to have the application run, but could not figure out a reason for this (described in the above link). The bootloader is placed at address 0x0, and the image is allocated from 0x10000 to 0xFFFFF. This shares the format discussed in SD Card Bootloader :how to using SD card to update existing firmware on CodeWarriror or KDS .

The programming of the image seems to be working correctly and the program runs, but seems to be missing features added using processor expert. I recently added low power modes into the project, which work when the program is loaded directly from the debugger, but not when loaded from the bootloader due to SMC_HAL_GetProtection() returning that low power modes are not allowed. The low power mode protection was set  in the application image but not in the bootloader; however, if I modify the bootloader to also allow low power modes, then it works properly.

Could anyone provide any insight into why the main application would be using what I assume to be the "system_MK64F12.c" file from the bootloader and not the one from the application? I am unsure what I am missing that makes some settings still shared between the two, which might also explain why I need to memset the SRAM.

Thanks,

Jared

[Alice_Yang]

Hello Jared,

- Have you test one simple project ,not the low power project , how about it ?

- What about the clock mode of your bootlaoder , PEE , FEI .. or ..?

If not the FEI clock , before jump to application , please set it to FEI mode.

- If the simple project can work well , i think you can show your low power project ,

  i can check it on my side .

Hope it helps

Alice

[kyati]

Hi Alice,

Thanks for getting back to me. I am using the 20Mhz FEI in the bootloader and 120Mhz PEE in the application. Changing the application speed to 20Mhz FEI makes no difference. With my simpler project without low power modes, the bootloader works only if I do the SRAM clearing workaround which I briefly described. I believe this is due to something being shared between the bootloader and loaded program that I cannot identify; for example, I noticed the low power mode protection was using the settings of the bootloader instead of the application. As I mentioned, the problem was resolved if I changed the power protection settings in the bootloader project.

I would greatly appreciate if you would look into my projects for me. As my current projects are fairly developed and set up for our custom board, I'll try to quickly create a simplistic K64 freedom board version of my them for your use with the same issues. I'll get an update as soon as possible.

Thanks,

Jared

[Alice_Yang]

Hello Jared,

Please pay attention that the power mode protection register only

can be written once after any system reset .

- I think first you should debug the simple project can work well on

the bootloader ,for example , you can create one simple LED project .

Hope it helps

Alice

[kyati]

Hi Alice,

Thanks for the information about the PMPROT register. It makes sense that the application could not rewrite the protection settings made by the bootloader since there is no system reset, only the jump to application; thus, setting the PMPROT in the bootloader resolved the issue.

I have been investigating the other issues I have described and believe that adding FreeRTOS to the project caused the problem. I was able to reproduce this on my custom board, the K64 freedom board, and the K64 tower board. I have attached three projects that demonstrate the problem for the K64 freedom board on very simple projects and would appreciate your input. The projects were formed in KDS using processor expert for K64 freedom and KSDK 1.3. All run at 20MHz FEI.

1. Bootloader project - based off of the example that you provided in SD Card Bootloader :how to using SD card to update existing firmware on CodeWarriror or KDS
   • Checks if "TestApp.bin" is present on the SD card. Is so, updates the program. If not, jumps to user application
   • Erases the flash from 0x10000 to oxFFFFF
   • Reads and flashes the binary information from the file in blocks of 512 bytes
   • Removes "TestApp.bin" from the SD card and jumps to user application
2. Baremetal test project
   • Adds debug console and RGB LED components in processor expert
   • Prints "Program Successful" and blinks the blue LED approximately every 1 second in main
3. FreeRTOS test project
   • Added default FreeRTOS component while only changing the heap settings to coalesc blocks in the second SRAM section
   • Adds debug console and RGB LED components in processor expert
   • Prints "Program Successful" and blinks the blue LED every 1 second in rtos_main

I load the bootloader on through KDS and then load the applications by naming the generated binaries to "TestApp.bin"  and putting them on the SD card. The baremetal project always programs and loads properly; however, the FreeRTOS project goes to default ISR after the jump. I can get it to run properly if I add to the end of the bootloader something to the effect of:

  memset((unsigned int *)0x1FFF0400,0,0x10000-0x400);
  memset((unsigned int *)0x20000000,0,0x30000);

I had also noticed that if the memset is done in the code, the bootloader will work even if the code is programmed back to the bootloader without the memset. This will last until the board is unpowered, which I assume is when the SRAM is reset.

I am additionally unsure if I need to de-initialize the sdhc or other peripherals and interrupts before the jump. I have tried variously ways of doing so but none resolve this issue.

If you can find anything I may be missing that fits these symptoms or can think of any other tests for me to run, please let me know.

Thanks,

Jared

[Alice_Yang]

Hello Jared,

Does the single freertos project can work well on your side ?

If yes ,  after flash the APP , please check the flash memory whether right ,

you can compare it with the memory when only downlaod the APP project .

BR

Alice

[kyati]

Hi Alice,

Yes, I changed the linker file to start at address 0x0 on the freertos testapp project and it runs as expected without the bootloader. I exported the memory from the memory module in KDS, and compared the flash of the bootloaded version running from 0x10000 - 0x16000 and the flash of the directly programmed version running from 0x0000 -0x6000. I then checked this against the binary file to determine if the differences were expected.

In a few places throughout the memory files, I found for example "000004E9" instead of "000104E9". These changes were expected I assume due to the 0x10000 difference in the linker file. Near the end there were a few shifts in the registers, which I found was due to the bootloader version having the directory "TestApp", while the directly programmed one was named "BaseTestApp" that also was shown in the binary file. Other than those changes, all of the contents and lengths were exactly the same. I believe that the programs are being flashed correctly.

Would you have any other ideas for me to check that may relate to the condition of the SRAM?