HCS12 Bootloader problem

[sebasira]

Hello guys!

I'm working with MC9S12A256B and CW 3.1, and I'm using bootloader from AN3275

The problem is that when I bootload my app (send .s19 via HyperTerminal) the reset vector is erased, inside address 0xFFFE I see 0x0000. So neither the bootloader nor the app runs, unless I manually set the PC = 0xF0C0 (Bootloader reset vector address). The strange thing is that all the other vectors (PLL, TIMER. COP, etc) are correct.

I try with a smallest app, wich doesn't use EEPROM variables and it worked fine, so I guess the problem is somewhere there. I've notice that when I've got a constant variable inside EEPROM page the bootloading process erase the reset vector.

I've define EEPROM segment as shown and then place variables using #pragma CONST_SEG EEPROM_DATA_PAGE .

SEGMENTS    PAGE_EEPROM = READ_ONLY  0x0400 TO 0x0FFF;END

PLACEMENT
    EEPROM_DATA_PAGE     INTO      PAGE_EEPROM;
END

The ONLY diference with the working app and the one that doesn't worksis that one puts variables inside EEPROM_DATA_PAGE and the other does not.

What could possibly be happening?

Thanks in advance!

PS: If you need the .s19 file or the complete .prm file ask, and I'll post it

[CrasyCat]

Hello

Can I get the .prm, .map and .s19 files for both working and non working case please?

CrasyCat

[sebasira]

Of course you can!! I'll make a rar file and upload it to Megaupload. I think that's better than posting the whole code here. It would be unreadable.

Here's the link: .MAP .s19 .PRM files

If for some reason you can't download it, I'll upload them to a web-site I'm working on.

The bootloader code is the one from AN3275. It's untouched!

Thanks!

[sebasira]

Oh! How stupid am I? I forget I can attach a file here...

[sebasira]

Any clues here?

[CrasyCat]

Hello

I took a quick look at the provided files.

Then look OK from a linker perspective. Also reset vector is correctly initialized after I load them in the simulator.

I do not have the appropriate HW available to be able to test what is happening when downloading the .s19 files in real HW..

There might be a problem with flash programmer some how.

There are 2 things you could try (from my perspective):

  - Try to download the .s19 with CodeWarrior HC12 V5.1 (Problem may have been fixed in the mean time).

     You do not need to import the whole project in the IDE. Just start Hi/WAVE and try to download from

     there after you have opened the project.ini configuration file.

  - Submit a service request to get a support engineer to run some test son real HW.

    Note that they might check on the latest release of the software as well. There will be no update to

    CodeWarrior V3.1 any more.

CrasyCat

[sebasira]

Thanks for your response CrasyCat!

Do you think is a problem related to CodeWarrior? I don't know much, but I don't think that's the problem. Please excuse me if I question what you suggest, it's because my lack of knowledge.

Loading both apps with HiWave works fine, the problem is when I try to load them sending the .s19 to the bootloader, via RS232. 

I was thinking that it could be some "error" on the .prm files or something like that. Or may be I should change something in the bootloader.

I'll try to make it more detailed:

I've got the 3 apps:

   1- Bootloader (the untouch code from AN3275)

   2- My App without EEPROM variables @0x0400 (the "working" version)

   3- My App with EEPROM variables @0x0400 (the "not working" version)

If I load any of those 3 apps with HiWave, each app works great.

Now, I only load the bootloader with HiWave. Enter bootloading mode, send the "working" version .s19 via RS232. It works great! Reset vector points to the bootloader, and there, it decides to execute the bootloader or jump to my app.

But, if I enter bootloading mode and send the "not working" version .s19 via RS232, it wouldn't work beacuse reset vector points to nothing (0x0000) If, when debbuging, I manually set the Program Counter to the Bootloader address (the value that should be at the reset vector) it works fine, and as before, the bootloader decide what to execute.

Three things to take note:

   + When reset vector points to nothing, all the others vector points to where they should. I found that strange beacuse, if there were some memory overlapping, the others vector wouldn't be pointing to their respective routines.

   + I needed to compile the bootloader using CW v4.6 because inside its .prm file, it set a segment as READ_WRITE and loads code there (the one to be executeted in RAM), and CW 3.1 don't allow a READ_WRITE attribute for a CODE_SEGMENT.

   + Why when a variable is defined in 0x0400 (EEPROM) the bootloader erase the reset vector? Because that seems to be the problem. I'll attach the AN3275 bootloader code.

Thanks for taking the time to read it!

[kef]

I opened AN3275 pdf and found that EEPROM is expected to be at 0x2000! You have it 0x400. Also, since there's dedicated EEPROM menu, I'm not sure if this bootloader is able to program common flash+EEPROM S19 file, but I didn't read whole AN, maybe it's possible.

[sebasira]

Hi kef!

Yes, I've already read about how the AN3275 re allocate the memory map, but it also says that:

"In user’s code, registers, RAM, and EEPROM start addresses may be remapped to wherever the user may
see fit."

Also try putting EEPROM at that address (0x2000), and the same thing happend.

About the dedicated EEPROM menu, I think, maybe the problem is there... I initialize the EEPROM variables, perhaps that's causing the problem. To initialize them I do as follow:

#pragma CONST_SEG EEPROM_DATA_PAGE  const byte EEPROM_MSJ_PREGRABADO_1[EEPROMsize_MSJ_PREGRABADO]={"MENSAJE 1"};#pragma CONST_SEG DEFAULT

Note: I post the code because maybe you find something odd there 

I'll try without initialization... I think I've already try it, but it's worth trying again.

By doing so, the bootloader won't need to erase/write EEPROM, rigth? If so, no EEPROM is touch and this issue about the dedicated EEPROM menu would be dismissed

[sebasira]

Well, it does the same if no init is done:

#pragma CONST_SEG EEPROM_DATA_PAGE  const byte EEPROM_MSJ_PREGRABADO_1[EEPROMsize_MSJ_PREGRABADO];#pragma CONST_SEG DEFAULT

It's driving me crazy! What's doing the bootloader??? I don't understad much about linkers and compilers, but how can this definition interfere with the bootloading process?

All I want to do is to stablish that at some defined address (in EEPROM), there is a certain amout of bytes associated to EEPROM_MSJ_PREGRABADO_1.

I know I can do it like this:

#define EEPROM_MSJ_PREGRABADO_address      0x0400#define EEPROM_MSJ_PREGRABADO_size           EEPROMsize_MSJ_PREGRABADO

 And then when I want to access that variable, just do a cast like this:

EEPROM_ptr = (byte*) EEPROM_MSJ_PREGRABADO_address;

I've done this in previous projects, before I learn how to use #pragmas and how to define segments in .prm file.

Besides, if I do it like I used to, I need to keep track of addresses, sizes, and alignment. Be defining a variable, and having always sizes that have modulo 4 equal 0 (%4 =0) the problem solves it self.

I hope this information can help solving this issue!

[kef · Accepted solution]

#pragma CONST_SEG EEPROM_DATA_PAGE
  const byte EEPROM_MSJ_PREGRABADO_1[EEPROMsize_MSJ_PREGRABADO]​;
#pragma CONST_SEG DEFAULT

^^ It won't remove EEPROM addresses from S19 file if EEPROM_DATA_PAGE is defined with READ_ONLY in PRM file. Try changing EEPROM_DATA_PAGE segment definition from READ_ONLY to NO_INIT in PRM.

Alternatively you can edit BBL file to remove EEPROM addresses from S19 file or to put them to eeprom.S19 or other file.

[kef · Accepted solution]

#pragma CONST_SEG EEPROM_DATA_PAGE
  const byte EEPROM_MSJ_PREGRABADO_1[EEPROMsize_MSJ_PREGRABADO]​;
#pragma CONST_SEG DEFAULT

^^ It won't remove EEPROM addresses from S19 file if EEPROM_DATA_PAGE is defined with READ_ONLY in PRM file. Try changing EEPROM_DATA_PAGE segment definition from READ_ONLY to NO_INIT in PRM.

Alternatively you can edit BBL file to remove EEPROM addresses from S19 file or to put them to eeprom.S19 or other file.

[sebasira]

And that solve the problem!!!

Thank you very much kef! Thak you! Thak you! Thak you!

I'd like to go a little bit further now...

1- Do you know why that happend?

2- Can you explain me a little mor about the NO_INIT definition? It doesn't matter if it is READ_WRITE or a READ_ONLY segment? This is only applyable to DATA segements, rigth?

[kef]

In case you don't specify initializer for object allocated in READ_ONLY segment, object is initialized with zeros and S19 file includes S-record(s) for EEPROM data. NO_INIT makes object not initialized.

[sebasira]

Yes I can see that EEPROM is not initialized, and that's perfect! 

I didn't know about it, everytime I worked with EEPROM I've never used NO_INIT, so all variables were initialized to 0x00, and I've to declare them (manually) as 0xFF so EEPROM always begin erased. Now I don't need to do that any more.

Thanks one more time!