"Error 18" from CPROGHCS08 (Programming QE96 part.)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

"Error 18" from CPROGHCS08 (Programming QE96 part.)

1,184 Views
JohnPassaniti
Contributor I

My target is a QE96.  I've written an application for it using CodeWarrior's small memory model (so there is no banking).  Until recently, I've had zero problems compiling, linking, and programming the target. Please read that last sentence again.

 

Things started to go wrong when I needed to change the layout of objects in memory.  Specifically, my program crossed the 0x7FFF boundary and is now in the 0x8000 to 0xBFFF window.  And to be specific, I have placed a data structure at the end of that window (at 0xBF80).   The problem is during programming.  When it tries to write the data structure I placed at 0xBF80, it gives me an "Error 18" and notes the address.

 

I am not having any problems compiling or linking my code.  When I inspect the memory map and the resulting S19 file, it is *exactly* what I want (and expect).  The only thing that isn't working here is programming.  Please read this paragraph again.

 

I contacted P&E Micro, but the response I received doesn't match Freescale's data sheet for the QE96.  The representative claimed that it doesn't matter that I'm using the small memory model; he claims that the window between 0x8000 to 0xBFFF is set to the first bank.  Well, no.  Freescale's datasheet says that the PPAGE register is reset to 2 after every reset, which to me means that if nothing touches the MMU, the entire CPU address space between 0x0000 and 0xFFFF is simply the first four banks of flash (minus RAM, periphrials, and reserved areas).

 

So my questions:

 

1.  Can someone with experience with the QE family confirm that the part works as described above (and in the datasheet)?  Specifically, that if PPAGE is never touched, then 0x8000 to 0xBFFF is the third page (page #2) of flash?

 

2.  Can someone with experience using P&E Micro's USB Multilink Interface tell me if you've had any problems locating objects in the 0x8000 to 0xBFFF window, and if so, how you resolved them?

Labels (1)
0 Kudos
3 Replies

557 Views
kef
Specialist I

1. Yes, on reset PPAGE==2. CW 6.3 is flashing 0x8000-0xBFFF to PPAGE=0 instead of PPAGE=2 and it looks like it is not fully compatible with small memory model. If you want small memory model, then you should exclude ppage window from the memory map.

 

2. You can edit bbl file so that 0x8000-0xBFFF in S-records is moved to paged addresses 0x28000-0x2BFFF. Then you could upload S-records to your target. Unfortunately debugging will be problematic. Here's how modified bbl could look like

 

OPENFILE "%ABS_FILE%.s19"
format=motorola
busWidth=1

SRECORD=Sx

 

origin=0
len=0x8000
destination=0
SENDBYTE 1 "%ABS_FILE%"

 

origin=0x8000
len=0x4000
destination=0x28000
SENDBYTE 1 "%ABS_FILE%"

 

origin=0xC000
len=0x1000000
destination=0xC000
SENDBYTE 1 "%ABS_FILE%"

 

CLOSE

 

 

Problem with 0xBF80 probably was caused because nonpaged 0x3F80 is the same physical memory as ppage=0, 0xBF80.

0 Kudos

557 Views
JohnPassaniti
Contributor I

Thanks for the reply.  I'm relatively new to CodeWarrior, and I'm finding, in general, it is painful relative to some of the other toolchains I've used.  In the particular case, the programming/debugging environment screwing around with the PPAGE register is forcing me into decisions I shouldn't have to make.  The underlying MCU is fine.  The tools... not so much.

 

Regardless, thanks for the suggestions.  I'm hopeful with what you suggested, I can get this to work.

 

0 Kudos

557 Views
kef
Specialist I

Looks like I have better solution for using small memory model with QE96/QE128 and CW6.3

 

1. To solve flashing issues (flash 0x8000.0xBFFF to ppage2) we can use flashing algorithm for (nonbanked) JM60. I'm not sure it is safe 100%, so please don't use it for production programming.

To do so in debugger click MultilinkCyclonePro -> Advanced Programming/Debug Options... -> Choose Alternative Algorithm and select 9S08JM60.S8P in <CW root>\prog\P&E foldef.

 

2. Problem with JM60 algorithm is that clock trimming registers are at different addresses. So you need either to turn off clock trimming or copy S8P file to different file and edit it. Replacing these lines in S8P for JM60

 

WRITE_BYTE_AND_SYNC=C0/00000049/  ;Bus Freq ~ 2MHZ
09BIT_TRIM=004A/004B/01/FFAF/FFAE/001E8480/
WRITE_BYTE_AND_SYNC=00/00000049/  ;Bus Freq ~ 16MHZ

with these lines from S8P for QE128/QE96

 

WRITE_BYTE_AND_SYNC=C0/00000039/  ;Bus Freq ~ 1.048576MHZ
09BIT_TRIM=003A/003B/01/FFAF/FFAE/00100000/
WRITE_BYTE_AND_SYNC=00/00000039/  ;Bus Freq ~ 8.388608MHZ

seems doing what we need

 

 

3. While in debugger go to MultilinkCyclonePro menu and change device to (nonbanked) QE32.

 

4. Go MultilinkCyclonePro->Debugging Memory Map... and modify bottom address of 00008000 - 0000FFFF memory block. You need to set it to 0x2080.

 

 

Let me know if it is working for you.

0 Kudos