K64 Bootloader, CAN DeInit

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

K64 Bootloader, CAN DeInit

886 Views
wfwf
Contributor II

Hello,

I'm having a problem in creating a CAN bootloader on a K64F 1M 120MHz platform. Both the BootL and the Target Application should use the CAN BUS but as I initalize the peripheral unit in different ways, the final result is that in the Target Appl the CAN is not well initialized.

For instance, using the ProcExpert to create the BootL I have different vector table addresses and I don't have interrupts, while in the main application I use them.

The problem arises when I try to "DeInit" the CAN peripheral at the end of the BootL, just before jumping to the code. Since in the Target Appl the CANBUS doesn't work, I suppose the device hasn't correctly closed,

any help/hint??

thank you!

Labels (1)
0 Kudos
3 Replies

586 Views
wfwf
Contributor II

Hi Ping, thank you

The application code is working fine if placed at the beginning of the flash or at the position it would have when the bootloader is also placed in, so I think the application is fine.

When I initialize the CAN peripheral in the Bootloader, with its own IntVector, its own speed etc, I can use it correctly while inside the Bootloader.

What I do at the end of the BootL is to DeInitialize the CAN (no other peripheral are used) and jump inside the main Appl. Inside the Appl I have to use again the CAN so I Initialize it again with different IntVector, speed, etc but It's not working anymore.

That's why I think there's something that doesn't really work in the DeInit function..but do you mean only DeInit when you say "shut down the peripherals"?

A little workaround for this has been to create the BootL from the project of the main Appl, so that the CPU speed and all its parameters are the same. Futhermore, even the CAN peripheral has the same parameters and so its' working both in the BootL and in the Main Appl, here even if the DeInit shouldn't work, is not a big deal cause no settings are changed

thank you, regards

W

0 Kudos

586 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Thanks for your reply.

According to your reply, we can assure that the application can works well independently.

I think the root cause is the difference of the clock mode configuration between the bootloader and application.

And many customers also have the kind of issue, so we usually suggest the customer to disable the module before to jump the application code.

As my experience, the method is very useful.

Hope it helps.
Have a great day,
Ping

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

0 Kudos

586 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

First of all, can you tell me the application code whether work well without jumping from the bootloader or not?

And I'd highly recommend to shut down the peripherals before jump to the application code, then initialize these peripherals again in the application code.

Hope it helps.
Have a great day,
Ping

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

0 Kudos