Problem during Watchdog initialization

[ganeshvijayakum]

Hi,

I am working on S12G micro, and  we initialize watchdog CPMUCOP register in bootloader before jumping to the application.This is causing some irregular CAN error messages on to the BUS.

So, If I don't initialize the Watchdog in bootloader when valid application is present, we don't observe CAN error frames on the bus.

I am not able to identify what is the relation between the Watchodg and CAN driver.

Please refer the configuration below for watchdog and PLL,

   CPMUCOP   = 0x44;

   CPMUPROT    = 0x26;
   CPMUCLKS    = 0x80;
   CPMUOSC     = 0x80;
   CPMUREFDIV  = 0x80;
   CPMUSYNR    = 0x01;
   CPMUPOSTDIV = 0x00;
   CPMUPLL     = 0x00;

So if I comment the CPMUCOP initialization I am facing the problem mentioned above.

Please let me know of there is any relation between watchdog initialization to the CAN driver performance.

Thanks in advance.

Regards,

Ganesh Vijaya Kumar P.

[ganeshvijayakum]

Hello Radek,

Looks like I have identified the root cause for the issue mentioned.

Here, In bootloader I do initialize the CPU registers as shown below,

   CPMUCOP   = 0x44;

   CPMUPROT    = 0x26;
   CPMUCLKS    = 0x80;
   CPMUOSC     = 0x80;
   CPMUREFDIV  = 0x80;
   CPMUSYNR    = 0x01;
   CPMUPOSTDIV = 0x00;
   CPMUPLL     = 0x00;

while (!UPOSC){}

CPMUCLKS   |= 3;

Now, in application I  do initialize the initialize the CPU registers in the same way except watchdog.

   CPMUPROT    = 0x26;
   CPMUCLKS    = 0x80;
   CPMUOSC     = 0x80;
   CPMUREFDIV  = 0x80;
   CPMUSYNR    = 0x01;
   CPMUPOSTDIV = 0x00;
   CPMUPLL     = 0x00;

while (!UPOSC){}

CPMUCLKS   |= 3;

So now, please look into the observations below,

1) When I flash application only, and monitor the CPMUCLKS register value at run time, I can observe 0x83,

2) When I flash bootloader only, and monitor the CPMUCLKS register value at run time, I can observe 0x83.

3) But when both the bootloader and application are flashed on to the bus, and controll is in application now I can read CPMUCLKS value as 0x82 only.

So in the 3rd observation I can see COPOSCSEL0 is not set, but I need that bit to be set because OSCCLK should be used for COP on my project.

So, One more observation I have made in application is I am initializing the CPMUCOP far later the initialization of CPU clock regusters.

What I observed is when control jumps from bootloader to application watchdog is already initialized and I am not able to set the COPOSCSEL0 forever.

What should I do to set the COPOSCSEL0 bits in application when bootloader is present.

Is there any dependency between the COPOSCSEL0  and CPMUCOP registers?

Please let me know your comments.

Thanks in advance,

Regards

Ganesh Vijaya Kumar P.

[RadekS · Accepted solution]

Hi Ganesh,

Yes, that is a good catch. However, I cannot see any direct connection to CAN communication.

Yes, there is a dependency between CPMUCLKS and CPMUCOP registers. The COPOSCSEL0 and COPOSCSEL1 bits may be modified in normal mode only you write into CPMUCOP register.

There is one exception based on the next dependency:

“COPOSCSEL0 can only be set to 1, if UPOSC=1. UPOSC= 0 clears the COPOSCSEL0 bit.”

So, if you lose your OSCCLK clock validation (UPOSC= 0), you may set COPOSCSEL0/ COPOSCSEL1 bits again.

The write into CPMUSYNR or CPMUREFDIV automatically clears LOCK and UPOSC bits.

So, it seems that you lose your OSCCLK clock validation just prior CPMUCLKS   |= 3; command in your application.

There is also recommendation:

After writing CPMUCLKS register, it is strongly recommended to read back CPMUCLKS register to make sure that write of PLLSEL, RTIOSCSEL, COPOSCSEL0 and COPOSCSEL1 was successful.

Possible solutions:

1. You may initialize CPMUCOP after your last modification of CPMUCLKS. However, this means that bootloader will be not protected by COP watchdog.
2. You may initialize CPMUCOP in bootloader after the last bootloader’s CPMUCLKS modification. In that case, you must ensure that UPOSC will be cleared also in the application (PLL settings change/disable and enable external oscillator) and you have to check correct settings of COPOSCSEL0 and COPOSCSEL1 bits in CPMUCLKS register after their writing.

For example:

   //-------- select clocks ----------------
   while(CPMUCLKS != 0b10000011)            // After writing CPMUCLKS register, it is strongly recommended to read 
       {                                    // back CPMUCLKS register to make sure that write of PLLSEL,
                                            // RTIOSCSEL, COPOSCSEL0 and COPOSCSEL1 was successful.
          CPMUCLKS = 0b10000011;                  
                    /* ||||||||-------- COPOSCSEL0 - COP Clock Select 0
                       |||||||--------- RTIOSCSEL - RTI Clock Select
                       ||||||---------- PCE - COP Enable During Pseudo Stop Bit
                       |||||----------- PRE - RTI Enable During Pseudo Stop Bit
                       ||||------------ COPOSCSEL1 - COP Clock Select 1
                       |||------------- CSAD - COP in Stop Mode ACLK Disable
                       ||-------------- PSTP   - Pseudo Stop Bit
                       |--------------- PLLSEL - PLL Select Bit
                    */
       }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

You should also use Oscillator status interrupt and/or PLL lock interrupt (the PLL un-lock will clears

UPOSC bit) and write correct value of CPMUCLKS register when OSCCLK clock is validated again.

I hope it helps you.

Have a great day,
Radek

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

[ganeshvijayakum]

Hello Radek,

Thanks for your reply, as you said I moved CPMUCOP initialization after the last modification of CPMUCLKS.

And It seems it has resolved the problem.

And for your information, there is a relation between CAN error frames and CPMUCOP in my project,

Because I set CPMUCOP before initialization of CPMUCLK in bootloader and jump to application,

Now I am not able to set the COPOSCSEL0 bit, and If this bit is not set I am re-initializing the CPU PLL clock,

for example,

if (CPMUCLKS != 0b10000011){
   CPMUPROT    = 0x26;
   CPMUCLKS    = 0x80;
   CPMUOSC     = 0x80;
   CPMUREFDIV  = 0x80;
   CPMUSYNR    = 0x01;
   CPMUPOSTDIV = 0x00;
   CPMUPLL     = 0x00;
   while (!UPOSC){}
   CPMUCLKS   |= 3;
}
and I am executing the above piece if code at random time...;-)
So, the re-initialization of the PLL clock is leading the CAN error frames issue.
Hope you can understand the relation between COP and error frames in my project.
Thank you very much for your support.
I appreciate your co-operation in resolving the problem.
Regards,
Ganesh Vijaya Kumar P

[RadekS]

Hi Ganesh,

Thank you very much for your explanation. Now it is clear.

The randomly executed PLL re-initialization in your application may block execution of CAN communication code.

Have a great day,
Radek

[RadekS]

Hi Ganesh,

I am not aware of any direct connection between CAN module and COP watchdog module.

However, it looks like some problem with unexpected interruption – COP watchdog resets MCU during CAN message transmitting.

Unfortunately, you didn’t specify how you apply jumping between bootloader and application and whether CAN is used also in the bootloader.

In fact, if COP watchdog is enabled, it cannot be disabled (appropriate bits may be written just once in normal mode) unless your MCU is in the special mode.

I suppose for now that there is some COP reset when you jump into the application.

Could you please monitor reset pin for any unexpected reset?

When you jump into the application by MCU reset and you use CAN in bootloader for loading flash content, please switch CAN module into Sleep mode and wait until this operation finishes prior MCU reset. This will prevent against generation broken CAN messages.

For example:

CANCTL0_SLPRQ = 1;         //sleep mode request

while(CANCTL1_SLPAK == 0); //wait for acknowledge of sleep mode

The time when the MSCAN enters sleep mode depends on a fixed synchronization delay and its current activity:

• If there are one or more message buffers scheduled for transmission (TXEx = 0), the MSCAN will continue to transmit until all transmit message buffers are empty (TXEx = 1, transmitted successfully or aborted) and then goes into sleep mode.
• If the MSCAN is receiving, it continues to receive and goes into sleep mode as soon as the CAN bus next becomes idle.
• If the MSCAN is neither transmitting nor receiving, it immediately goes into sleep mode.

I hope it helps you.

Have a great day,
Radek

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

[ganeshvijayakum]

Hi Radek,

I really appreciate for your reply.

We are jumping to the application from bootloader when a valid application flag is present, and re-flashing supported using bootloader(CAN is enabled in bootloader).

I have monitored the COP ISR by toggling a test pin but no watchdog reset is observed(None of the reset is being issued).

For your information I am not bothered about the error frames received while jumping from bootloader to application.

I am bothered about the error frames while CAN is running after successful re-flashing of the module.

Please look into the following observations mentioned,

      1) When I flash only application and run the module only with application, No error frames are observed on the bus.

      2) When I flash only bootloader and run the module only with bootloader, No error frames are observed on the bus.

      3) When I flash bootloader and re-flash the application, error frames are observed on the bus at random period of time.

      4) When I flash bootloader(commented watchdog initialization) and re-flash the application, No error frames are                       observed on the bus.

      5) When I flash bootloader and re-flash the application( with watchdog commented), error frames are observed on the           bus.

To make you clearly understand please look into the pictures below code flow for steps mentioned above,

So, I would like to know why the watchdog initialization is causing the CAN error frames.

Please let me know your comments.

Thanks in advance,

Regards,

Ganesh Vijaya Kumar P

[RadekS]

 Hi Ganesh,

Thank you for more details.

According to your description, the error frames are observed on the bus only when both bootloader and application are loaded into flash and when bootloader contains COP initialization to 0x44.

From my point of view it rather looks like some issue in memory range overlaps:

1. The bootloader with COP init code is probably longer. Could you please check map/s19 files whether bootloader and application do not use the same flash area?

Optionally you may try to replace COP init code in bootloader by few asm NOP; commands to keep the same code length and watch the application behavior.

2. I suppose that there is memory overlapping in the case of RAM. Your application may use some uninitialized variable which causes that 0x44 is sent over CAN instead their default value. Please check default values of application variables after application start.

3. There might be some pointer in the application which points to bootloader flash area. Please ensure whether you reference correct data.

Unfortunately, you didn’t specify your jump into the application. Is it through MCU reset like in AN4258 bootloader case or you just use JMP/JSR/CALL commands?

In the second case, two initialization of COP watchdog (in bootloader and in the application) have no sense. The appropriate bits in CPMUCOP register may be written just once in normal mode.

Are you sure that you jump to application’s _Startup() function with stack and RAM variables initialization?

I hope it helps you.

Have a great day,
Radek

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

[ganeshvijayakum]

Hello Radek,

Great, that is a good catch.

1. The bootloader with COP init code is probably longer. Could you please check map/s19 files whether bootloader and application do not use the same flash area?

Ans: I have compared the .s19 file for both the application and bootloader and please look into the below pictures,

Looks like blocak 0 in bootloader and application are overlapped. Is that what you are expecting?

Please let me know if this may effect the micro controller functionality.

Yes, I am using JSR to jump from bootloader to application and it jump to the _Startup() routine of the application code, in which we initialize stack and RAM.

I will be very happy to see your reply again...:-)

Thanks for your support.

Regards,

Ganesh Vijaya Kumar P.

[ganeshvijayakum]

I am sorry the block 0 which is present in the bootloader and application s19 file is used to check if valid apoplication present.

It seems problem is with something else...