s19 End of block

[mpc8377e]

Hello All,

The last line in the hex file(.s19) generated by CodeWarrior has end of block information indicated in red below. The records (S7, S8, or S9) contains a starting address for the program.

S04D0000433A5C446F63756D656E747320616E642053657474696E67735C656D622D726167686B756D5C4D7920446F63756D656E74735C50726F6A6563745C62696E5C50726F6A6563742E61627364

S11AC000CF05004A800F3C4A80003C0000C011C01500000000000090

S105FFFEC0003D

S2243C8000C60A873B10EFC6555B3F585B3F20F7FEC00DFDC00B270E35ED31EC316970043487

S21C3C8020FB310326F2FEC00FEC31270BED31180A30700434F920F10A78

S804000000FB

In the above case the starting address for the program is 0x0000 and it is default address. What needs to be changed in PRM to get the starting address for program as 0xC000?

Attached my PRM file.

I tried to set "VECTOR ADDRESS 0xC000 _Startup". But still can find the starting address as 0x0000 in the generated hex file.

Please suggest.

/Raghu

Original Attachment has been moved to: Project.prm.zip

[Lundin]

Short answer:

You are probably just looking for a way to relocate your main() function. This can be done through SECTIONS... END and PLACEMENT....END in the .prm file, followed by a #pragma CODE_SEG my_main  in the main() file. There is an app note for that, somewhere on the Freescale site.

Long answer:

The real starting address of a S12 MCU is always FFFF, because that is where the reset vector address is programmed. Therefore the last line of your s-record doesn't need to know the starting address - the S8 row is ignored and therefore set to all zeroes. The address FFFF, or rather the whole interrupt vector table, is programmed along with the rest of the flash. So you will find the actual start address in some S1/S2 row that programs the memory at FFFF.

When you create a default Codewarrior project, it programs the location of _Startup into the interrupt vector table, at address 0xFFFF. You shouldn't try to change that in the .prm. By default it would have said something like VECTOR ADDRESS 0xFFFF _Startup, or possibly VECTOR 0 _Startup.

The _Startup routine does the following: It sets the stack pointer. It may map physical memory depending on S12 type and CW version, registers INITRG, INITRM and INITEE for registers, RAM and EEPROM respectively. It may or may not enable the COP, depending on CW version. It initializes global and static variables as enforced by the C standard, but only if you picked "ANSI C startup" rather than "minimal startup" when you created the project. When all is done, it calls main().

If you are not familiar with all of the above things done by the _Startup, or if you don't know how static initialization and storage duration work in C, then don't try to fiddle with _Startup. Use the default CW project and leave it at that.

If you are an "advanced" user who needs optimal performance, standard compliance or simply someone who is annoyed at the mysterious magical _Startup file, you could replace it with an implementation of your own. I described how to do that here: HCS12 banked model & "near" function pointers.

That post is for an older version of Codewarrior but the general idea is the same. It will have to be ported to suit the specific S12 derivate as their peripherals may vary. One shouldn't attempt to implement ISRs for peripherals that aren't physically present in the silicon, for example.

There is also an app note describing how to write your own interrupt vector table in C, similar to the code I posted on that thread, but that app note will not use standard C.

[mpc8377e]

Thanks Daniel for the information. The requirement is such that we need to start the application from 0xC000 location. I will take help from your earlier post HCS12 banked model & "near" function pointers and let you know.

[GordonD]

Raghu,

Let me clarify Daniel's answer. The transfer or start address contained in the S7 (32-bit address), S8 (24-bit address) or S9 (16-bit address) is generally only used by a debugger to set the initial value of the Program counter after it has completed loading the S-Record file. It does not contain the address that is programmed into the Reset vector (0xfffe - 0xffff). Examining the S-Records you provided in your original post, the following S-Record contains the start address, 0xc000, which is programmed into the reset vector when a Flash loader programs the S-Record into Flash:

S105FFFEC0003D

The S7, S8 and S9 records are use to mark the logical end of the S-Record file. The transfer or start address contained in these S-Records was only used back in early days of "personal computers" when all the computer contained was a small ROM based S-Record loader and all programs were loaded into RAM.The transfer/start address allowed for a "load-and-go" functionality.

Regards,

Gordon