Bootloader problem for Kinetis KL15 (Hard Fault)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bootloader problem for Kinetis KL15 (Hard Fault)

1,820 Views
Jack_
Contributor I

Hello All,

I’m writing a bootloader for a Kinetis KL15Z128VFM4  to load a program through a UART. The problem that I have is that I get a Hard Fault error in the middle of the process.

Previously to that I have made the same process in a Kinetis K10 project without problems.

The process that a try to do is the next:

  1. Start condition: The only code I have in KL15 flash is the bootloader program.
  2. When start the KL15 the bootloader copy the needed functions to RAM.
  3. Disable all interrupts.
  4. Jump to main bootloader function to start the process (located in RAM).
  5. Start a PC program that sends the commands and data to load the new code in the KL15 flash with the next sequence:
    1. Erase the flash above bootloader area (that allows that if the power supply fails the bootloader start again).
    2. Send the code to fill the erased flash area.
    3. Erase the initial flash area occupied by the bootloader
    4. Send the code to fill the initial flash area.
    5. Make a KL15 reset to start the new program.

When I try to do this process I get a jump to Hard Fault interrupt (interrupt number 3 located at address 0x0000000C of vectortable). This interrupt occurs at the step 5.c : after deleting the flash sector number 2,  when the PC program sends a new command interruption occurs.

I can see the problem because I run the program through the debugger.

If I run the program step by step (F5, F6 KDS debug) I can not get the problem appears.


I have checked all the program and once started the bootloader in RAM I no longer call any routine in flash.

Serial communications I make by pooling because I cannot use any interrupt.

In my old project running on a K10 have no problem using the same method.

Any suggestions to solve the problem? (It seems a particular problem of  KL15)

Thanks in advance,

Joan

0 Kudos
6 Replies

1,158 Views
Jack_
Contributor I

Hello All,

Finally I found the problem.

The “offending “ code was caused  by the ‘C’ instruction “switch” that generate some call to a function generated by the compiler  (that I can’t see debugging)  in FLASH. When I delete the flash area where this code is the program crash (obviously).

The solution has been to change the two "switch" that I had in the program for several "if". The “if” instruction don’t generate any call to a flash routine.

In my old project with K10,  CW10.4  use the Freescale compiler (mwccarm.exe) that doesn’t generate the call to a flash function with the “switch” instruction . With this project with KL15  use the GNU compiler (arm-none-eabi-gcc.exe) that generate this problem.

Thanks for the received proposals.

Best regards.

Joan

0 Kudos

1,158 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi  Joan Faine,

  That's good to hear you solved the problem.

  It is really difficult to find the problem if caused by the complier . Thank you for your sharing solutions.

  If you still have problem, please let me know!


Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,158 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Joan Faine,

      You said :" This interrupt occurs at the step 5.c : after deleting the  flash sector number 2,  when the PC program sends a new command interruption occurs. "

      Could you tell me, is the interrupt caused by the flash sector erasing code ? or  after MCU receive the new command from PC?

      Which command your PC  are sending? Whether your flash sector erasing is successed?

      You need to find which code caused this interrupt at first, you can refer to this post to find the postion which caused the hardfault interrupt:

      Debugging Hard Faults on ARM Cortex-M

.

Jingjing

0 Kudos

1,158 Views
Jack_
Contributor I

Hello Jingjing,

I have using the post that you indicate to try to find the offending position in the code.

The hard fault interrupt is not caused by the flash sector erasing code.

In fact, erase routine finishes without error. I can even send new commands from the PC to erase other sectors (or the same sector) and KL15 responds correctly.

But if I send other commands from the PC, such as a command to read a  flash area, the program crash and enters the hard fault interrupt.

This command to read the contents of the flash does not fail until I have not deleted the critical sector of the flash (sector 2).

I inserted the code for debugging the Hard Fault that appears in the post that you suggested me but the address captured corresponds to a zone with no program code (this area is set to 0xFF). The captured address is not always the same, have appeared the following addresses: 0x200, 0x208 and 0x20C.

For me it makes no sense that the program jumps to an address in the flash in which there are no program code and this only happen after erasing the sector 2 and then sending a command to read a flash sector. At that moment the bootloader program is running only in RAM !!

Do you have any ideas that could help me?

Thank you very much.

Joan

0 Kudos

1,158 Views
yasuhikokoumoto
Senior Contributor I

Hello Joan,

I might give one suggestion.

K10 includs FTFL flash module and KL15 include FTFA flash module.

All flash commands of K10 are not supported by KL15.

If your FCMD would be 0x08 (Erase Flash Block), the hard fault could occur.

If you used 0x09 (Erase Flash Sector), I am sorry and I have no more suggestion.

Best regards.

Yasuhiko Koumoto.

0 Kudos

1,158 Views
Jack_
Contributor I

Hello Yasuhiko,

I’m using 0x09 (Erase Flash Sector). I’ve checked the datasheet to compare the commands I use, and all are the same in both models K10 and KL15.

Thanks anyway for the suggestion.

Best regards.

Joan Fainé

0 Kudos