S19 and SX Files...

[bigd]

I have "Inherited" an HCS12 job which was compiled on an early version of CW (5.1 I think). It produced .S19 files.

My new development system using CW5.9 produces .SX files - these can be used by my USBDM programmer o, and I can download and run new code.

What I cant do is load the .S19 files using the USBDM - I get the message "Program data not within target Flash Memory" - so I guess the programmer is reading the .S19 file incorrectly and trying to put the code at the wrong loaction in the memory map.

Is this a known problem? Is there any info available about the structure of S19 and SX files? Is there a file format converter available?

Again, I'm new to HCS12, so hope Im not wasting anyone's time with my ignorance..... thanks for listening!

[BlackNight]

Hello,

About the file format: see

http://en.wikipedia.org/wiki/S19_%28file_format%29

You can use as well the prog\decoder.exe to decode an S19 file: this will produce a listing with all the items in the file decoded.

Hope this helps,

BK

[bigd]

Thanks for that, BlackNight - but it has thrown up more questions for me than answers!

In the .SX file that I have generated (which loads ok) - there are S1 (16 bit address) records with addresses in the range 0x0000 - 0xFFFF, which is what I would expect from a 64K flash CPU.

But there are also S2 (24 bit address) records for 0x3C8000 range, which cant be in the 64K map, can it? Yet this file loads and runs OK!

As for the .S19 files I am not able to load (yet I know work, because they were in use up until very recently) - these contain S2 type records (24 bit address,w hich shouldn't be necessary in a 64K map?) and all seem to want to load the code at 0x0F0000 to 0x0FFFFF, which is a 64K area, but definitely outside of the range of the 0-64K address map!

I thought I had a reasonable grasp of embedded systems - I have only been working on (a variety of) embedded micros since about 1985 ( ! ), but I am very confused......

Why would CodeWarrior generate output addresses outside of the address range of the micro? Why would some programmer devices seem to accept this, but others wont? I must be missing something (big) ......

Again, thanks for your input....

[freescale_dude]

Just a scientific wild guess here, but what memory model are you using with each set of the tools? That information can be found in the compiler options settings panel. It sounds like one set of files was generated with a banked memory model and the other with a small memory model.

---Tom

[bigd]

Kef and Tom,

thanks for your comments - wish I could embed them in block caps in the Freescale datasheet!

banked memory - hadnt realised that banks were accessed using addresses outside the 64k map - so I can see now why both projects have adresses in ranges 0x3Cxxxx and 0x0F0000.

Banking settings - Tom, in the compiler options settings panel, the "memory model" box is ticked in both projects. The compiler command line arguments both say -Mb, so I guess I'm compiling for a banked environment. The project .prm files also have references to paged segments :

PAGE_3C = READ_ONLY 0x3C8000 TO 0x3CBFFF;
PAGE_3D = READ_ONLY 0x3D8000 TO 0x3DBFFF;

To give a little more information, I have been given this project with just the source files and a project (mcp) file (not even a memory map!). The mcp file was from an older version of CW (dont know which one) and is not fully compatible with CW 5.9, but got me started - in particular, I couldnt recover the memory model info from it, so I guessed "banked" based on the code, and built a new project under CW 5.9 \ HCS12(X) 5.0.14.

This has explained a lot of my problems, but not the original one - ie, trying to load the old project .S19 files using the USBDM - I get the message "Program data not within target Flash Memory". Since it seems ok to have addresses in the .Szz files outside of the 64k area, I dont understand why this message occurs. I have checked the file using decoder.exe, and the only thing I can see which seems "a bit odd" is that all code is being directed to load at 0xF0000 and above - ie, all code is banked? I know that at least some of the code must exist in base memory for startup, etc, so I am at a loss to see how this ever worked at all?

Again, thanks to all for your input - I have learned a lot already!

[freescale_dude]

OK, one other thing to check. What processor is chosen in the Compiler Settings? An S19 files indicates the outpt is for an S12 part, while an SX file hints that the output is for an S12(X) part. Kef will probably correct me on this, but I think the memory maps of those two parts are different.

---Tom

[bigd]

Tom,

thanks for the thought, but the "latest" code is set to HCS12 \ MC9S12A64, produces a .SX file and  works on a 9S12A64 target (definitely not 12X). I dont know what the earlier code was set to, but the .S19 file (apparently) also works on a 9S12A64 target (though I havbent been able to get it to load on my system).

[bigmac]

Hello,

If you are using a third party programmer that expects S2 records to be in linear format, rather than the "non standard" paged format, the attached tool should provide the required file conversion.

Regards,

Mac

[kef]

Bigd, CW5.1 is the latest CW for S12(X). 5.9.0 is the version of IDE, not the version of whole CW product. To determine version click about, and then Installed Products, and then at top of Installed Products window you will see real CW version.

You also need to always specify derivative, which you are talking about. I had to figure it from reading other your posts. It's S12A64

• In the .SX file that I have generated (which loads ok) - there are S1 (16 bit address) records with
• addresses in the range 0x0000 - 0xFFFF, which is what I would expect from a 64K flash CPU.

Not really. A64 has 64k of flash memory. Whole address space is more than 64k. S12 has paged memory. Those pages of flash, which are mappable to page window at 0x8000-0xBFFF, need to be addressed somehow.

There are two known conventions how to specify address of banked S12 flash memory: banked address and linear address. Banked is specified as page_no * 0x10000 + cpu_address. So the address of byte at bottom of PPAGE 0x3C is encoded as 0x3C8000.

Linear address is page_no * size_of_page + page_offset. So the same byte as above is encoded as 0x3C * 0x4000 + 0 = 0xF0000.

By default CW debugger wants S records with banked addresses. Some other tools, like P&E Prog12z wants S records with linear addresses and even dislikes S1 records with data for nonbanked memory. There's a way to make CW debugger loading S records with linear addresses. You need to add

SRECISHCS12LINEARADR=1

environment variable line to debuggers ini file.