Running in and out of Debuger

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

Running in and out of Debuger

Jump to solution
1,023 Views
rayhall
Contributor V

I have a project that reads and writes to the Atmel AT45DB041B flash IC. When run in the debuger everything works correctly. If I power up the project out side the debugger it locks up at the part of the code related to reading from the AT45DB041B. The communication with the AT45DB041B is using SPI. I have tried different prescaler values and it does not help.

 

 

What is different with running in and out of the debuger that would cause this problem ?

 

Ray.

Labels (1)
0 Kudos
1 Solution
766 Views
kef2
Senior Contributor IV

Hi

Some more details, just checked.

Both Connect (Reset) button in connection manager and Reset Target (Ctrl+R) button do reset target to special single chip mode. This is bad to debug with all normal mode protections engaged.

1) Prerequisites. CW 5.1. USB-M-12 rev B. Should work for other Multilink or Cyclone revisions, but I'm trying with USB-ML-12 rev B.

2) In Hiwave go to HC12MultilinkCyclonePro -> Connect or Communication menu. Connect or Communication depends on BDM connection state, connected or not.

3) Check the most bottom checkbox Show this dialog before attempting to connect... This is not necessary.

You did it already.

4) On first time connect, in checkbox from above is checked, hit Connect (Reset) button, and observe flash code programming messages. Otherwise (Show... checkbox is not checked) debugger won't show connection manager and skip to flash code programming.

4) After code flashing is done, go to HC12MultilinkCyclonePro->Communication... . This will show connection manager dialog.

5) Hit Hotsync button.

5) Power cycle target or pull and release /RESET pin low.

6) Hit Halt (F6) button to stop target. Then debug as usual. To debug from start you need to use some (un)conditional loop to stop target after power on or reset.

There's another way, but it must depend on CW and Multilink versions. Perhaps target model matters also.

1) S12C64. Code is flashed to target, debugger is closed. Target is power cycled (normal mode).

2) Hit debug from CW

3) Debugger starts and "Loading a new application will stop the execution of the current one" dialog box pops up.

4) Hit Cancel

5) "Do you want to load application symbolic information?" click Yes

6) Halt (F6) target. Target executes in normal single chip mode.

Code to demonstrate the difference between normal vs special operating modes is below. Should compile for S12A/B/C/D. In normal mode it hangs in the first while() loop, in special mode in for(;;) loop.

#include <hidef.h>      /* common defines and macros */
#include "derivative.h"      /* derivative-specific definitions */

void main(void) {
  /* put your own code here */
 


    EnableInterrupts;

   FCLKDIV |= 1;
  
   FCLKDIV &= 0;

   while(FCLKDIV & 1) {
      asm("NOP");
     
   }


  for(;;) {
    _FEED_COP(); /* feeds the dog */
  } /* loop forever */
  /* please make sure that you never leave main */
}

Regards

Edward

View solution in original post

0 Kudos
8 Replies
766 Views
kef2
Senior Contributor IV

Most likely it is write-once protected register issue. By default debugger runs your target in special single chip mode, in which write-once protection is disabled. You hit reset, and your targets ends in normal single chip mode, in which write-once protection is engaged. For example one will fail initializing flash or EEPROM clock dividers properly on older S12A/B/C/D/E families, if write to PRDIV8 bit and xDIVy bits is done not in the same CPU write cycle. All bits have to be initialized using single write to write-once protected register.

To debug the issue, use BDM debuggers hot-plug mode. I don't remember exact instructions how to do it, please search forums for write-once issues and hot-plug mode or debugging in normal single chip mode.

Regards

Edward

0 Kudos
766 Views
rayhall
Contributor V

Edward,

Thank you for the reply. I have searched for write-once and hot-plug and I am no more enlightened as to what they are and how you use or change them.

If I have to change PDRIV8, then how do I change it ?

I have tried moving the position of the ReadDataFromFlash(); function and it made no difference. I tried just after the initialization statements and before the enable interrupts. Also after the enable interrupts. I tried adding a one second delay before and after ReadDataFromFlash();

I have never used a debugger before as the IDE for the AVR's I used in the past, never had a debugger. To me they are useless if they give a different result to the real world ?

Ray.

0 Kudos
766 Views
kef2
Senior Contributor IV

Ray,

It's called hotsync, not hot-plug. Not often used feature, I always forget how P&E calls it in Multilink connection manager.

1) Prerequisites. CW 5.1. USB-M-12 rev B. Should work for other Multilink or Cyclone revisions, but I'm trying with USB-ML-12 rev B.

2) In Hiwave go to HC12MultilinkCyclonePro -> Connect or Communication menu. Connect or Communication depends on BDM connection state, connected or not.

3) Check the most bottom checkbox Show this dialog before attempting to connect... .This lets you chose next time what debug mode you want:

  3.a) you hit Connect (Reset) button. In this case debugger pulses RESET pin, keeping BKGD pin low. Target is reset to special single chip mode, in which write-once protections are disabled. Good mode to flash code to target, since after reset no code is executed until target receives BDM command to do something.

  3.b) you hit Hotsync. In this case debugger doesn't touch RESET pin, operating mode is preserved, target keeps running if it was running. You can inspect target memory or hit Stop button to stop code execution.

You can't change PRDIV8 twice in normal modes. Should be no problem, even if you are switching CPU clock to faster or slower (PLL), since S12 flash/EEPROM clock dividers divide oscillator clock, which you can't change on the fly, it is defined by your crystal or external oscillator.

  • I have never used a debugger before as the IDE for the AVR's I used in the past, never had a debugger. To me they are useless if they give a different result to the real world ?

But debugger allows debugging your code in both modes. Still problem?

Edward

0 Kudos
766 Views
rayhall
Contributor V

Edward,

1. I connected the P&E Multilink and selected to display the Connection Manager every-time the debugger is selected.

2. I clicked Hotsync and after the program was loaded I clicked the Run arrow. The ReadDataFromFlash(); worked as it should.

3. From CodeWarrior I selected debug again, and this time selected Connect(Reset). I clicked the Run arrow and the ReadDataFromFlash(); worked as it should.

4. Disconnected the P&E Multilink and the power supply from my project board, then reconnected the power. Now it would not run and stopped at the ReadDataFromFlash(); function.

I know it is stopping there as I can comment out ReadDataFromFlash(); and it does not lockup.

Sorry if I am doing something wrong...

Ray.

0 Kudos
766 Views
kef2
Senior Contributor IV
  • 2. I clicked Hotsync and after the program was loaded I clicked the Run arrow. The ReadDataFromFlash(); worked as it should.

Wrong. Connect (Reset) button (reset to special single chip mode) should be used to flash code to target. You should expect problems flashing code if you start flashing in Hotsync mode.

After "Connect (Reset) programming, you may close debugger, power cycle target, connect to target using Hotsync button, stop target where it is (perhaps hangs already). If you want debug from start in Hotsync "mode", then you need to add some while forever loop. So: you cycle power, target keeps executing forever loop, you connect with Hotsync, hit stop button, adjust PC pointer to skip for(;;). hit run button, or step, or add breakpoints etc..

Operaing mode is essential here. You should remember that Connect button in connection manager and (perhaps) reset button do change operating mode to special single chip. And that's the problem. To debug in normal mode, don't use Connect (Reset) button. I'm not sure now about debuggers reset button (different button than Connect (Reset). It may also change operating mode to special. I'm not sure, don't remember when I used Hotsync seriously last time.

Edward

0 Kudos
767 Views
kef2
Senior Contributor IV

Hi

Some more details, just checked.

Both Connect (Reset) button in connection manager and Reset Target (Ctrl+R) button do reset target to special single chip mode. This is bad to debug with all normal mode protections engaged.

1) Prerequisites. CW 5.1. USB-M-12 rev B. Should work for other Multilink or Cyclone revisions, but I'm trying with USB-ML-12 rev B.

2) In Hiwave go to HC12MultilinkCyclonePro -> Connect or Communication menu. Connect or Communication depends on BDM connection state, connected or not.

3) Check the most bottom checkbox Show this dialog before attempting to connect... This is not necessary.

You did it already.

4) On first time connect, in checkbox from above is checked, hit Connect (Reset) button, and observe flash code programming messages. Otherwise (Show... checkbox is not checked) debugger won't show connection manager and skip to flash code programming.

4) After code flashing is done, go to HC12MultilinkCyclonePro->Communication... . This will show connection manager dialog.

5) Hit Hotsync button.

5) Power cycle target or pull and release /RESET pin low.

6) Hit Halt (F6) button to stop target. Then debug as usual. To debug from start you need to use some (un)conditional loop to stop target after power on or reset.

There's another way, but it must depend on CW and Multilink versions. Perhaps target model matters also.

1) S12C64. Code is flashed to target, debugger is closed. Target is power cycled (normal mode).

2) Hit debug from CW

3) Debugger starts and "Loading a new application will stop the execution of the current one" dialog box pops up.

4) Hit Cancel

5) "Do you want to load application symbolic information?" click Yes

6) Halt (F6) target. Target executes in normal single chip mode.

Code to demonstrate the difference between normal vs special operating modes is below. Should compile for S12A/B/C/D. In normal mode it hangs in the first while() loop, in special mode in for(;;) loop.

#include <hidef.h>      /* common defines and macros */
#include "derivative.h"      /* derivative-specific definitions */

void main(void) {
  /* put your own code here */
 


    EnableInterrupts;

   FCLKDIV |= 1;
  
   FCLKDIV &= 0;

   while(FCLKDIV & 1) {
      asm("NOP");
     
   }


  for(;;) {
    _FEED_COP(); /* feeds the dog */
  } /* loop forever */
  /* please make sure that you never leave main */
}

Regards

Edward

0 Kudos
766 Views
rayhall
Contributor V

Edward,

That worked. I was able to find what was wrong and fixed it.

I am warming to the debugger...maybe one day I will love it

Thank you for all your help.

Ray.

0 Kudos
766 Views
rayhall
Contributor V

Edward,

I am using the TBDML and it does not have these options. I do have a P&E  Multilink that I will try.

Ray.

0 Kudos