topic Loading code onto MC9S12DP256 in CodeWarrior for MCU

Loading code onto MC9S12DP256

brunie — Wed, 16 Jun 2010 19:28:32 GMT

Hi,

I used Codewarrior to write the code for my MC9S12DP256. As output I have a few .s19 and .phy file types, but am having issues trying to load either onto the microcontroller. I attempted to use MGTEK miniIDE, but when trying to load onto FLASH, I did not see the * for the progress (which I saw when I loaded a sample program). I have done some research already into reformatting these output files but it has just made me more confused. I believe it may have something to do with the addresses that are contained in the files but am not confident in changing them. I also have a SRecCvt program, but haven't had any success with it either.

Can anyone recommend a procedure to accomplish this task? Any software that works better than others? My output files are only about 10-12 lines so even manually adjusting for me is an option. Which file should I even be using (s19 or phy? ... one with Serial Monitor in filename or not?)

I appreciate any assistance provided.

Project.abs (s19)

S0030000FC
S9030000FC

Project.abs (phy)

S0420000433A5C446F63756D656E747320616E642053657474696E67735C616272756E656C6C655C4465736B746F705C4E65775C62696E5C50726F6A6563742E61627370
S2240FC000CF1100790011CC09395B105A124A8006304A8000300000C01BC038000000007977
S21E0FC0200011A7CC01095B105A12C60D5B13C6105B0A06C0003D0B0B0000F8
S2240FFF80C036C036C036C036C036C036C036C036C036C036C036C036C036C036C036C036ED
S2240FFFA0C036C036C036C036C036C036C036C036C036C036C036C036C036C036C036C036CD
S2240FFFC0C036C036C036C036C036C036C036C036C036C036C036C037C036C036C036C036AC
S2240FFFE0C036C036C036C036C036C036C036C036C036C036C036C036C036C01FC01FC01FD2
S2240C00004A802F3020FEFEC017FDC015270E35ED31EC3169700434FB310326F2FEC019EC21
S2240C002031270BED31180A30700434F920F10A790039C6B15B3A1D024E0279024B4D381296
S2240C00404D3C404D0D937902631D026BC379025379025B7902434D1E407900CB96CC96CF96
S2180C00607900CDC633875CC85ACAC6245BCB4C020710EF0AFF
S9030000FC

Project.absHCS12_Serial_Monitor.abs (s19)

S05A0000433A5C446F63756D656E747320616E642053657474696E67735C616272756E656C6C655C4465736B746F705C4E65775C62696E5C50726F6A6563742E61627348435331325F53657269616C5F4D6F6E69746F722E616273AD
S123C000CF1100790011CC09395B105A124A8006304A8000300000C01BC01F000000000019
S104C020001B
S2243080004A802F3020FEFEC017FDC015270E35ED31EC3169700434FB310326F2FEC019EC7D
S22430802031270BED31180A30700434F920F10A790039C6B15B3A1D024E0279024B4D3812F2
S2243080404D3C404D0D937902631D026BC379025379025B7902434D1E407900CB96CC96CFF2
S2243080607900CDC634875CC85ACAC6245BCB427A0103C6307B0105407A0104C6020729C6F8
S2243080800307257901037B01057A0104C6497B0100C6307B0115C6497B0110790113447A07
S2183080A001144C330710EF0A7B0103C6307B01057A01043D41
S804000000FB

Project.absHCS12_Serial_Monitor.abs (phy)

S05A0000433A5C446F63756D656E747320616E642053657474696E67735C616272756E656C6C655C4465736B746F705C4E65775C62696E5C50726F6A6563742E61627348435331325F53657269616C5F4D6F6E69746F722E616273AD
S2240FC000CF1100790011CC09395B105A124A8006304A8000300000C01BC01F000000000009
S2050FC020000B
S2240C00004A802F3020FEFEC017FDC015270E35ED31EC3169700434FB310326F2FEC019EC21
S2240C002031270BED31180A30700434F920F10A790039C6B15B3A1D024E0279024B4D381296
S2240C00404D3C404D0D937902631D026BC379025379025B7902434D1E407900CB96CC96CF96
S2240C00607900CDC634875CC85ACAC6245BCB427A0103C6307B0105407A0104C6020729C69C
S2240C00800307257901037B01057A0104C6497B0100C6307B0115C6497B0110790113447AAB
S2180C00A001144C330710EF0A7B0103C6307B01057A01043DE5
S9030000FC

*** NOTE - the second line is a continuation of the first

Re: Loading code onto MC9S12DP256

kef — Thu, 17 Jun 2010 23:15:53 GMT

I'm not familiar with MGTEK. I could be wrong, but Isn't it just a serial terminal and some board running dBug12 software? I'm not familiar also with dBug12, but if I remember well, dBug12 occupies a lot of flash and to load flash you should first erase it and use bootloader that comes with dBug12 to load flash. Or, you could use one board with dBug as a serial to BDM adapter, and you could load and debug (via your board with dBug12) code on 2nd board (target). Check dBug12 documentation.

Codewarrior produces all two possible S records variants. In S19 file you have S-records with banked addresses, in PHY file - S-records with linear addresses. IIRC, dBug12 wants PHY file.

Re: Loading code onto MC9S12DP256

brunie — Fri, 18 Jun 2010 21:45:14 GMT

While in bootloader mode (by setting appropriate jumpers), I am able to load my program if I first erase the flash, which is great! Now, in order to execute the program, do I need to switch back to the FLASH/EVB mode (again, by switching the jumper) and enter the start address? Or can I run the program from bootloader?

Thanks

Re: Loading code onto MC9S12DP256

kef — Fri, 18 Jun 2010 23:48:52 GMT

I don't know. I think d-bug12 manual should answer these questions. You may get it here along with bootloader and d-bug12 S-records files:

http://cache.freescale.com/files/soft_dev_tools/software/app_software/dbug_rom_monitors/DB12S12FW.zip

Re: Loading code onto MC9S12DP256

brunie — Mon, 21 Jun 2010 20:45:29 GMT

Thank you, that document provides the necessary procedure which involves setting the jumpers to Bootloader, erasing and then loading the Flash, then setting jumpers back to the Flash mode. There is one last point that I am unsure about, which is in regards to the execution of the program. The document states that once the jumpers are set back to Flash mode,

" This will cause the bootloader startup code to jump to the address in the alternate reset
vector at $EFFE. When the user code is programmed into Flash, an address MUST be placed in
the Reset vector position ($EFFE) of the alternate interrupt vector table. "

Does anybody know where this is located in a typical program? I have gone through the various files that Codewarrior generates for the program but cannot seem to find the alternate interrupt vector table or reset vector located at $EFFE.

Re: Loading code onto MC9S12DP256

kef — Tue, 22 Jun 2010 00:16:26 GMT

Codewarrior new project wizard generated project defines single reset vector. You may find it in PRM file:

VECTOR 0 _Startup

Number 0 ^^ here means vector number zero counting from the top of 16bits address spece. 0 - vector at 0xFFFE, 1 - vector at 0xFFFC, 2 - vector at 0xFFFA and so on.

You could change 0 to 2048 to move vector to 0xEFFE. (2048 is (0xFFFE-0xEFFE)/2 )

VECTOR 2048 _Startup

You can also use vector addresses instead of vector numbers:

VECTOR ADDRESS 0xEFFE _Startup

You may also define interrupt vectors in C files using interrupt keyword :

#pragma CODE_SEG NON_BANKED

interrupt (VectorNumber_Vspi0+2048) spi0isr(void)
{
}

Vectors at 0xExxx will overlap ROM_C000 segment defined in PRM file. You should trim upper end of that segment to make linker happy.

Re: Loading code onto MC9S12DP256

brunie — Tue, 22 Jun 2010 01:04:00 GMT

From the quote I posted above, is it saying to start the program at $EFFE or to place the startup address at the location of $EFFE?

In my .map file, it indicates the startup entry point is 0xC000 so should I use this as the line in the .prm ?

VECTOR ADDRESS 0xC000 _Startup

Thanks

Re: Loading code onto MC9S12DP256

kef — Tue, 22 Jun 2010 01:40:15 GMT

Vector is like pointer variable in C, variable that contains address of something (address of interrupt service routine or address of startup procedure ir our case). So if your map file shows that _Startup routine is at 0xC000, you must initalize byte at 0xEFFE with 0xC0, and byte at 0xEFFF with 0x00.

This will cause the bootloader startup code to jump to the address in the alternate reset vector at $EFFE.

MCU default reset vector at 0xFFFE points to Bootloader startup routine. Bootloader startup routine checks jumpers, then jumps to the address stored in secondary "reset" vector at 0xEFFE.

When the user code is programmed into Flash, an address MUST be placed in the Reset vector position ($EFFE) of the alternate interrupt vector table.

In other words don't forget to program vector at 0xEFFE.

Re: Loading code onto MC9S12DP256

brunie — Tue, 22 Jun 2010 02:17:29 GMT

Oh ok, that clarifies the process. Is there a particular location that I need to initialize the bytes (0xEFFE and 0xEFFF), or can I simply indicate 0xEFFE = 0xC0 and 0xEFFF = 0x00 at the start of my main.c?

Thanks!

Re: Loading code onto MC9S12DP256

kef — Wed, 23 Jun 2010 01:15:08 GMT

Didn't I answered that in message from 2010-06-21 08:16 PM?