Programming NMIN-12A256B with Serial Loader

[tangoz]

I'm using CodeWarrior Special Edition V3.1 development IDE on a WindowsXP platform. I'm developing for the MC9S12A256B chip that came integrated onto the NMIN-12A256B board with D-Bug12 Bootloader V1.0.0. Using HyperTerminal I can successfully transfer the NMIN provided srecord file, rtiled.s19 to the chip, and after I reboot to application the Leds flash. When I try to download the program I created (srecord with the s19 extension) the D-Bug12 Bootloader issues a message "S-Record Code/Data Length Is Odd".

I checked the PRM file, and the memory mapping for RAM did not reflect the mapping shown in the documentation I received with the NMIN board for the Serial Loader option. The documentation showed RAM remapped to start at 0xD000. The PRM file had RAM starting at 0x1000. I made the following changes to the CPU Bean Module to try to realign memory mapping in the Build of the PRM file to what the NMIM documentation showed.


CPU Bean used: CpuMC9S12A256BCPV

Bean Properties:
Internal RAM mapping changed to $D000

Bean Build Options:
Memory Area(0) Address changed to D000
Size changed to 2FFF

Memory Area(1) Address unchanged at C000
Size changed to 1000

I still received the same error when I tried to load my program srecord after rebuild with the new build options. The new PRM file did show the RAM remapped to 0xD000.

I'm lost. I think I need to see the PRM file generated by NMIN when they did the Build for the demo Led program. If I could see that file, I could probably incorporate at least the correct memory mapping into the PRM file for my program. If New Micro would provide the complete project file for their led demo program (including the PRM file), that would be even better.

I spoke with MetroWerks tech support and they recommended using the BDM port to load, completely removing the D-Bug12 program. Of course, they don't have NMIN board specs, so that would be their recommendation. I think if we used the BDM port load, CodeWarrior would accurately generate the memory map (and other files in the Build). That means purchasing the P&E Multilink USB interface.

If there are any other suggestions as to how to address this "S-Record Code/Data Length Is Odd" D-Bug message, I'd appreciate hearing. Thanks.

[nmitech]

I spoke with MetroWerks tech support and they recommended using the BDM port to load, completely removing the D-Bug12 program. Of course, they don't have NMIN board specs, so that would be their recommendation. I think if we used the BDM port load, CodeWarrior would accurately generate the memory map (and other files in the Build). That means purchasing the P&E Multilink USB interface.
If there are any other suggestions as to how to address this "S-Record Code/Data Length Is Odd" D-Bug message, I'd appreciate hearing. Thanks.

Same here. I have contacted MetroWerks tech support on the same problem in the past but nothing is solved up until today eventhough the tech said he will inform me if there any fix for it. The only thing that I don't understand is the Srecord generates by Codewarrior is not compatible for the Serial Bootloader. Where Metrowerks is own by Motorola and so is DBUG12 monitor and Bootloader firmware are also written by Motorola... Make the story short, here is what i did to work around the " S-Record Code/Data Length Is Odd" problem. Instead of generate S28 Srecord from Codewarrior You can also generate S19 srecord. Once you have the S19 file, use the Srecord conversion utility to convert it to S28 record. This S28 is compatible for the serial bootloader to download. I have not test this on any big size program so i can not say if it is 100% compatible. Atleast it works for my little test program. Good luck!

By the way, you can download the srecord converion utility here,
http://www.newmicros.com/download/appnotes/HC12/SRecCvt-GUI.zip

[tangoz]

Thanks for the info. I did download the Cvt utility from the link you provided.

My CodeWarrior set-up was generating on its own a s19 file in (project)\bin. NMIN provided Cvt utiilities on their floppy to convert to S19 (I think). So, if I'm reading your response correctly, I should run the Cvt utility from your link on the s19 file generated by CodeWarrior.

By the way, no matter what project name I use, the IDE always generates the (project)/bin directory files as Simulator... For instance, Simulator.abs.s19. I guess that's because I have the Simulator selected as the target. Is there a way to get a more project oriented name assigned there?

Also, is there a chance that NMIN will provide the project files or at least PRM file for their demo programs - at least the led demo? I'd sure like to see the memory mapping.

Thanks again.

[nmitech]

Just in case you missed this. Here is the HCS12 download page, http://www.newmicros.com/store/product_details/hc12files.html
This page can be found on the NMIN-12A256B product details page, and the file you need is "LEDS Example programs for NMIN-12A256B" . It is locating on the bottom of the page and it has all the info you are asking for. There are two example programs included in the zip file. One is for ram development, and one for flash. After you open the .mcp file, makesure to see the readme file first.

Note: the Srec Convert info that mentioned in the readme file is refering to the SrecCvt.exe Dos program. If you use SrecCvt-GUI.exe program makesure to select "Linear" option for both Input and Output File Format.
Device: MC9S12A256B
Memory: Flash
Operation: Convert File
Input File 1: "filename.phy"
Output File: "filename.S19"
All other options are unchecked, or leave them by default configurations. Keep in mind, the Output file extension is .S19 but it actually contains the S28 srecord file.

[tangoz]

Thanks for the info. I tried using the CVT-GUI program per your example, and it almost worked. The problem is that the CVT program is hard coded to identify flash start address as C000. But if the Serial Loader is configured on the chip (as mine is), that only leaves 1K of Flash to load because RAM is reloaded to D000 by the Serial Loader, so not enough program space left for the user program.. Can that start address be changed by the user (me) to access a different Flash location such as from 4000 to 8000?

I did check the PRM file for the LEDs example - no help there. It reflects the configuration where RAM is at it's normal address of 1000 (not relocated by Serial Loader.

The problem seems to be New Micros' Serial Loader configuration. With that Serial Loader resident and the memory map changed, it's incompatible with just about everything - CodeWarror and the CVT programs.

If New Micros is going to ship their board with Serial Loader pre-loaded, they need to clearly identify what Flash addresses are available for S-Record load and provide a tool to load the S-Record at the correct address. (or a way to reconfigure CodeWarrior).

I don't know, I'm a little disappointed with this New Micros board. It seems like there should be better user support for the Serial Loader pre-loaded configuration.

[nmitech]

tangoz, From the program you emailed me, there a two things you need to change in your program in order fix the "S Record out of range" downloading problem,

1. In the PRM file you need to move the ram to the default address register,
RAM = READ_WRITE 0x00001000 TO 0x00003FFF;
to avoid data memory conflicts with the program memory. If so error will generate when you compile the program.

2. In the Vector.C file, you need to change the interrupt vector address from 0xFF80 to 0xEF80. The reason when you use the Serial Bootloader, the interrupt vectors are moved out of the protected flash memory for user access. The Serial Bootloader appnote can be downloaded here. This is very handy for your programming reference. It is available on Motorola website for download,
http://www.newmicros.com/download/appnotes/HC12/AN2153.pdf

One thing i want to clarify, The Serial BootLoader & Dbug12 Monitor that preloaded with the NMIN-12A256B are Motorola Firmware. It is available for download on Motorola Web site as well. NMI does not make any change to it.

[tangoz]

Thanks again for all the help. I think the problem is solved. I reconfigured CodeWarrior to build the default memory map. That way, RAM was specified as you have it in your last post, Item 1. The interrupt address change (Item 2) to the Vector.C file seemed to be the real fix for correcting the "S-Record Out Of Range" problem. The error message did not reoccur through many rebuilds of the program after I changed the Vector.C file. I'll have to be sure to check that in future "code generations".

This was a tough problem and, as you stated, part of the problem is the several vendors involved. Motorola preloaded the Serial Bootloader & Dbug12 Monitor. I mistakenly thought that was from New Micros. New Micros provided the board with chip and integrated peripherals. Metrowerks provided the programming IDE, CodeWarrior. Whew, lots to learn.

Thanks again.