K32L2B31 Booloader no longer working after programming

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

K32L2B31 Booloader no longer working after programming

Jump to solution
1,654 Views
RicardoRuiz18a
Contributor II

Hi everyone. 

I'm using a  self made pcb with a K32L2B31VLH0A, the way i program the mcu is directly with the mcu USB pins to the pc and the app KinetisFlashTool.exe. I just simply press the nmi_b interrupt button and connect the usb to the computer, the tool recognizes the bootloader and then i'm allowed to program. 

This is a picture of the program result, mcu automatically disconnects if i don't mark the box "Auto connect".

RicardoRuiz18a_0-1638841934765.png

When i test the program in my pcb it correctly works, but i realized it no longer connects with the tool once i tried to.

This MCU was a replacement for a MKL27Z64VLH4. When we bought K32s i programed the KL27's hex to the K32 and it worked. I had no problems doing this and i was able to program x times. I don't know if doing this affects something inside the mcu and when i try to program a .hex created for a K32 i'm having troubles. I'm going to program a factory new K32 with its corresponding hex to see if it solves the problem.

To create the project with MCUxpresso i downloaded the sdk for the FRDM K32L2B. Once the code is written the way i'm generated the hex is by doing right click on .axf and then create .hex. The project properties was left by default and the error log isn't showing any errors or warnings.

Does enyone knows what am i possibly doing wrong? What can i do to avoid killing the bootloader?

In case you need the MCUxpresso project to check something just ask for it.

Thank you.

Labels (1)
0 Kudos
1 Solution
1,631 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @RicardoRuiz18a ,

Please check two field of the binary image. The first one is at address 0x40d. This is the FOPT initial value. FOPT[BOOTSRC_SEL] field control the boot source, from ROM or from flash. The second field is at address 0x3d2~0x3d3. This field is called peripheralDetectionTimeout. Please refer to table 13-3 in reference manual. If timeout value is too short, you can't catch up with it.

 

Regards,

Jing

View solution in original post

3 Replies
1,632 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @RicardoRuiz18a ,

Please check two field of the binary image. The first one is at address 0x40d. This is the FOPT initial value. FOPT[BOOTSRC_SEL] field control the boot source, from ROM or from flash. The second field is at address 0x3d2~0x3d3. This field is called peripheralDetectionTimeout. Please refer to table 13-3 in reference manual. If timeout value is too short, you can't catch up with it.

 

Regards,

Jing

1,616 Views
RicardoRuiz18a
Contributor II

Hi @jingpan.

Thank you very much. I compared the Byte on address you suggested 0x40d, between the Hex for Kl27z and the Hex for K32 and there was a difference, KL27z hex has 0x3D while K32 hex has 0x3F. I performed manually this change to the hex file and i can work with bootloader again once i program the mcu, but why is MCUxpresso doing that configuration? I saw in other posts that some people had doubts about modifying the linker file because KinetisDesignStudio has well specified the memory locations for the mcus but Mcuxpresso does not. And the problem was that the application is programmed from address 0x0000 and is overlapping the bootloader settings or something like that.

RicardoRuiz18a_0-1639515001067.png

Regards.

 

0 Kudos
1,608 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @RicardoRuiz18a ,

In startup_k32l2b.c, there is a structure Flash_Config. This value is defined to 0x400. Please check it.

 

Regards,

Jing