Running App after Bootloader Issue

[khumphri]

This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.

Posted: Thu Jun 2, 2005  10:49 pm

We implemented a bootloader that loads an application to the E128 processor. The bootloader does its job and reprograms the Flash, and then jumps to execute the new application at its entry point. The problem is that the new application crashes all the time, at different points without a pattern.

When flashing the new application directly with a P&E BDM box, it works without failure, so we know the application is not a problem.

When running the bootloader using the BDM box, and loading the new application, the new application works without a problem.

Has anybody experienced any similar problem when running applications after the bootloader?

Thank you for your help!

---

 

Posted: Thu Jun 2, 2005  11:02 pm

Are all the vectors for your application properly mapped to the actual vectors for the mcu? That would be my first guess. Are you using paged memory? Is your stack initialized properly?

I have a bootloader and it, as well as the application, run fine so I am guessing it is some small oversight.

---

 

Posted: Thu Jun 2, 2005  11:16 pm

There may be a problem with the BDM running in "Special Single Chip" mode while the stand alone runs in "Normal Single Chip" mode.

There has been a great amount of discussion of this on this list in the last week or so under the heading of "BOOTLOADER only works in debug mode". See the Archives.

A likely candidate is the COP watchdog, which is not enabled by default in "Special Single Chip" mode and is enabled in "Normal Single Chip" mode, but there are also many registers that become write-once in "Normal Single Chip" mode.

Please read the archives, the list wouldn't stand for rehashing this subject so soon after it was examined in great detail.

---

 

Posted: Fri Jun 3, 2005  1:39 am

I have been following these entries as well. Is there a document that describe which registers are write once, so that I can verify which ones could be causing the problems?

Regarding the COP, it is my undertanding that the initialization code of both the bootloader and the main application (both generated by Processor Expert) disables the COP watchdog. In addition, the program doesn't seem to reset and start over, but to hang (in different places each time).

One question is: if the initialization code of both the bootloader and the application is the same, the registers would have the same values when the application is initializing, and, therefore, would run properly. But this is not the case.

---

 

Posted: Fri Jun 3, 2005  3:32 am

I am not aware of any single place to look.

As the HC(S)-12 family has evolved the details of what is write once and a few registers that were "first write ignored in Special Single Chip Mode" (write twice!) have evolved.

The only safe thing to do is use the "device user's guide" to tell you about the different documents that describe registers for the particular part and version of that part, and then look carefully in the detailed register descriptions.

I just did a brief scan of the MC9S12E128 documentation, and found that there were write once registers which might trip up a boot loader mentioned in the CRG, PIM, Flash, EEPROM, MEBI, and MMC documents!

Some of these will probably affect only applications that attempt to use external memory, but the all seem to have some mode dependent differences.

I don't think that blindly trusting Processor Expert to do what you expect is wise. It depends on the authors of Processor Expert and you both correctly expecting the same "right thing". I would strongly recommend looking at the assembler listings or the disassembly of the loaded code to see what is actually going.

The startup code usually ends up being pretty straightforward, although looking at the source files that have conditional compilation to deal with the many options makes it look very complicated.

The last few weeks of list traffic on this subject have mentioned all of the pitfalls that come to mind, but I'm sure that there are a few more lurking in the shadows.

---

 

Posted: Fri Jun 3, 2005  7:00 am

> I have been following these entries as well. Is there a document that

> describe which registers are write once, so that I can verify which

The list archives, my mail "List of "write once" registers in HCS12 derivatives":

> Hello All,

>

> is there an exhaustive list of "write once" registers in HCS12

> derivatives?

>

> The modular documentation makes it very hard to find all places, and one

> can't even rely on searching the "write once" phrase.

>

> I know so far:

>

> INITRM

> INITRG

> INITEE ("on some devices") with the exception of the EEON bit

> MISC (EXSTR1 EXSTR0 ROMHM ROMON)

> MODE (several restrictions)

> EBICTL (External Bus Interface Control Register): ESTR

> IRQCR (IRQ Control Register): IRQE - IRQ Select Edge Sensitive Only

> PEAR: with the exception of the NECLK bit

> CLKSEL: COPWAI

> PLLCTL: SCME - Self Clock Mode Enable Bit

> COPCTL (CRG COP Control Register)

> ECLKDIV (EEPROM Clock Divider Register)

> FCLKDIV (Flash Clock Divider Register)

> CANCTL1 MSCAN Control 1 Register: CANE - MSCAN Enable

> DLCBCR1 (BDLC Control Register 1): CLKS

> DLCBARD (BDLC Analog Round Trip Delay Register)

> DLCBRSR (BDLC Rate Select Register)

> BFPCTLBF (Byteflight Port Control Register): BFEN

>

> Any more?

The question still applies. Maybe some new registers in the S12X?

---

 

Posted: Fri Jun 3, 2005  1:49 am

The vectors are properly mapped to the vectors of the MCU. This is from the fact that the application runs without problems when programmed independently (using BDM). In fact, when the application runs from the bootloader, it works for a few moments, but then it hangs.

Regarding the paged memory, we are indeed using paged memory (due to the size of the application). How would this affect the behavior of the application, when loaded with a bootloader?

Regarding the stack, it is initialized properly. Stepping through the initialization of the application after being launched by the bootloader, shows that the stack is correctly located (at the top address of RAM).

Did you code your own booloader or did you use some of the available bootloader code? Would it be possible to check your code to see if this give us some clue about the problem we're having?

Thank you for your help!

---

 

Posted: Fri Jun 3, 2005  4:22 pm

In the first point you mention that the application runs without problem when programmed from the BDM. I assume then that for the application all of the reset vectors are from FFD0 to FFFF. If this application is to run with a bootloader it must be recompiled with the vectors placed at a secondary location. For example...in the bootloader that I wrote the bootloader itself occupies F800 to FFFF and its vector table lies at FFDO to FFFF. The application's vector table however lies at F7DO to F7FF. All of the bootloader's vectors must point to this secondary table for the application to run properly. Maybe this is what you are doing already but it is unclear to me.

The paged memory caused me a few headaches as I recall due to not setting the page register properly in the bootloader to begin with. This was a while back so I am fuzzy on the details.

I wish I could show you the bootloader but it also performs some decryption routines that should be kept private.