AA4258 change boot mode

[kuksu]

hi
We are developing a CAN bootloader by modifying the source code of the s12x series serial bootloader.

However, during testing, the boot mode and app mode were specified to detect the level of the PP PIN through the button.

Since I can't add that switch to the actual product, do you have any ideas or ways to enter boot mode other than detecting the level of the PP pin through a button?

[lama]

Hi,

We are developing a CAN bootloader by modifying the source code of the s12x series serial bootloader. However, during testing, the boot mode and app mode were specified to detect the level of the PP PIN through the button. Since I can't add that switch to the actual product, do you have any ideas or ways to enter boot mode other than detecting the level of the PP pin through a button?

You can select any way you can but the principle in this application note requires reset status of the registers.

So possible solution is to use COP reset after bootloader start request.

For example:

• You can set some flag in the RAM variable which is after COP rested investigated and decision is made.
• You can write a flag to the EEPROM or FLASH and then use COP reset.

Some notes related to COP reset recognition can be found here…

https://community.nxp.com/t5/S12-MagniV-Microcontrollers/S12-FAMILY-DEVICES-COP-RECOGNITION-CONSIDER...

If you use S12XE then in the package at following page you can find COP example with comments.

The S12XD uses similar approach.

• There is a possibility to start the MCU always in bootloader mode and MCU waits for any bootloader not influencing input.  After some time when there is no request for loading new code then the main application is started.

Best regards,

Ladislav

[kuksu]

Thank you for answering. Ladislav.
I use 12xs, but is the above instructions in effect? Or if it's valid, I wonder if you should use another COP method or if you can use the same method as an example.

[lama]

Hi,

The S12XS is younger, less powerful, cheaper sibling of the S12XE (less peripherals, no XGATE, no EEPROM ....). COP can be solved in the same way.

I added the example. Plus DFLASH example on as an option.

Note, the COP is not debugable because during reset the MCU lost connection with the IDE.

Best regards,

Ladislav

[kuksu]

Thank you for your reply.

But unfortunately, I don't think I understood because I have little development experience.

The intention of my initial question was not to enter BOOT mode through a physical method such as an external switch.

The question was whether it could be controlled solely through S/W, excluding switches or separate H/W methods.

Do the examples or methods you answered fit the intent of my question?

Also, I didn't understand the following explanation.

(Note, the COP is not debugable because during reset the MCU lost connection with the IDE.)

I am currently working with Code Warrior (IDE) by connecting to the MCU on the development board via P&E USB multilink.

1. Does this explanation mean that if COP is reset while monitoring through IDE by connecting MCU and P&E, debugging is impossible because the connection between MCU and IDE is disconnected?

or not

2. Assuming that the P&E debugger is not connected...
In other words, does this mean that the COP of the written source code cannot be reset when the product is turned on, as in the development completion stage?

If the second is correct, it probably won't happen because you'll have to add a switch eventually, but I'm asking just to confirm.

Thank you Ladislav.

[lama · Accepted solution]

Hi,

Yes, I tried to explain you that the trigger to enter boot can be anything…. Received data via any peripheral or some SW event but what is important it is to set some flag and reset the MCU to have the registers in reset status.

So, lets imagine you boot the MCU via UART. You receive the boot request. Your action will be setting some flag in the ram or flash and reset the MCU by COP. Then the first code is checking this flag which decides whether you are going to boot or you go to the application. When you go to boot then after loading the new application code you change the flag and reset the MCU again by COP. Now the code will continue after the flag check into the application. Using RAM for flag require not to interrupt supply. The RAM stores the content while the MCU is powered. Moreover, you see that your application should contain the first trigger initialization (set flag and COP)

Why the COP is not debuggable?. The multilink start the MCU with special mode MODC=MODB=MODA=0 but before it they are synchronized. (to understand it I suggest to go through BDM peripheral, but you are not a BDM designer so it is wasting tme for you) When the COP resets the MCU the mode again depends on the setup of mentioned pin. However, synchronization between MCU and the multilink is lost. There is a possibility to connect multilink by hotsync command but you enter current status of the MCU…probably it is always running after COP reset. This is like debugging UART when you do not have scope to see Rx/Tx pins. You must test correct behavior and when it behaves as expected then you insert it into the app.

 No you do not need switch if you are able to understand principle. The switch also do not solves synchronization. Why? There is still a flag (in this case switch) which is tested by bootloader code after reset do decide whether to boot or run the application.

Best regards,

Ladislav

[kuksu]

Thanks for the detailed explanation.