Relocating RAM, Flashing

[blooy]

Our application maps RAM to 0x8000 on an HCS12C64 and has a Flash block at 0x0400 to 0x3FFF. The problem is that the Debugger using the P&E BDM tool initially has RAM at 0x0000 and writes code intended for the 0x0400 block into RAM. When the code runs the RAM is relocated and 0x0400 is blank so naturally it bombs when it gets to code that's supposed to be in that space. Any ideas?

Thanks, Bradley Looy

[blooy]

Our goal is to define a memory map for the C64 part that allows for as much use of FLASH as possible in the unbanked small memory model. Our solution was to relocate RAM to 0x8000 (the page window) to free up the 0x0400 to 0x3FFF FLASH space. 1. Can you suggest a better way to accomplish this? Note that we have a bootloader in the upper 4K of the FLASH. This is what our PRM file looks like:

SECTIONS
/* Application ROM block 1 checksum, img_type, ver @ 0x0400 (6 bytes) */
ROM_0400 = READ_ONLY 0x00000406 TO 0x00003FFD FILL 0xFF;
/* Application Checksum Verified flag @ 0x3FFE (2 bytes) - shared with bootloader */
/* Application ROM block 2 checksum @ 0x4000 (2 bytes) */
ROM_4000 = READ_ONLY 0x00004002 TO 0x00007FFF FILL 0xFF;
/* RAM Section */
RAM = READ_WRITE 0x00008000 TO 0x00008FFF;
/* Application ROM block 3 checksum @ 0x0C000 (2 bytes) */
ROM_C000 = READ_ONLY 0x0000C002 TO 0x0000EF7F FILL 0xFF;
/* Application Vector Table 0xEF80 - 0xEFFF */
/* Bootloader Block and Flash Security 0xF000 - 0xFF7F */
/* Defualt Vector Table 0xFF80 - 0xFFFF */
END

"I need to understand what you are trying to do here.
According to my understanding you are re-mapping RAM and ROM at run time (in your application). Am I right?

Where did you insert that re-mapping code?

Which version of CodeWarrior for HC12 are you using?"

We are using CodeWarrior for HC12 3.1. Yes the RAM is remapped at runtime. The INITRG and INITRM registers are the first thing the code sets up after reset. 2. Maybe you can answer why the debugger is not "getting" the memory map. The Debugger Memory Map is right but the problem is when the part is getting programmed.

[CrasyCat · Accepted solution]

Hello

I think the problem comes from the point that when you are downloading the application, the board is in the reset state (i.e. No FLASH at 0x300).

You need to let the debugger know about the remapping and make sure the remapping of the memory is performed before you download the code.

To achieve that I would suggest you to insert some commands in the startup.cmd and reset.cmd file, where you initialize the  INITRG and INITRM, ... registers.

You can use command wb there.

Example

  wb 0x12 0x40 /* Writes 0x40 at address 0x12.*/

I hope this helps.

CrasyCat

[blooy]

Hey thanks, that did help. Funny, we tried that before and didn't get positive results. However, we are getting errors during the load:



followed by....




And could you speak to our earlier question when you get time: "Our goal is to define a memory map for the C64 part that allows for as much use of FLASH as possible in the unbanked small memory model. Can you suggest the best way to accomplish this?"

Thank you much

[CrasyCat]

Hello

Honestly I am not sure that re-mapping FLASH to 0x400 will work from a hardware standpoint.

Also when you are starting the debugger, you are programming the flash. And I suspect the Flash programmer to use some memory in RAM as a workspace to load the programming applet and the code.

I do not have experience in modifying memory map on C64 to get linear addressing.

I would suggest you to go with the BANKED memory model and banked memory in that case. If you only have functions stored in banked memory, teh overhead is that that big.

CrasyCat

[blooy]

And we are shooting for a linear address space. This should keep the bootloader simpler.

[CrasyCat]

Hello

I need to understand what you are trying to do here.
According to my understanding you are re-mapping RAM and ROM at run time (in your application). Am I right?

Where did you insert that re-mapping code?

Which version of CodeWarrior for HC12 are you using?

Crasycat