Cannot read banked Data in a MC9S12C128, DRAGONfly12 from Wytec. Using CodeWarrior Ver 5.7.0

[kwik]

Using CodeWarrior Ver 5.7.0.

I have read Help etc trying to understand why I get this problem.
(I have read A LOT)

Here is the code that fails ;

const unsigned char *far wavPtr;

wavPtr = wav01;

char val = *(wavPtr+j);

Nomatter what j is ,I read 0xff ;

A little background ;
============================================
I created the project by starting with the Wizard in Codewarrior;

File->New->Selected New Project Wizard
Set "Project Name" to WavPlay
Set Location to something you like
Click Ok

Wizard starts->
Click Next
Select Correct MCU->MC9S12C128 in my case ,since its a DRAGONfly12 from Wytec
Select C as Language
Select No for Processor Expert
Select No for PCLint
Select ANSI startup code
Select None for float support
Select Banked memory
Select HCS12 Serial Monitor
Click Finish

Sooo I try to read the contents of the wav01 array ;

In Output.h it looks like this ;
---------------------------------------------
#pragma CONST_SEG __PPAGE_SEG WAV01
extern const unsigned char wav01[];

#pragma CONST_SEG __PPAGE_SEG WAV02
extern const unsigned char wav02[];

etc etc

In Output1.c it looks like this ;
----------------------------------------------
#pragma CONST_SEG PPAGE WAV01
const unsigned char wav01[]={
0x7E,0x03,0xA1,0x9E,0x98,0x8D,0x7F,0x72,0x6D,0x6F,
0x69,0x56,0x5C,0x77,0x90,0x9F,0xA6,0xA3,0x9A,0x8B,
etc etc

In the .prm file it looks like this
----------------------------------------------
PLACEMENT /* Here all predefined and user segments are placed into the SEGMENTS defined above. */
_PRESTART, /* Used in HIWARE format: jump to _Startup at the code start */
STARTUP, /* startup data structures */
ROM_VAR, /* constant variables */
STRINGS, /* string literals */
VIRTUAL_TABLE_SEGMENT, /* C++ virtual table segment */
//.ostext, /* OSEK */
DEFAULT_ROM,NON_BANKED, /* runtime routines which must not be banked */
COPY INTO ROM_C000;
WAV06 INTO PAGE_3D;
WAV05 INTO PAGE_3C;
WAV04 INTO PAGE_3B;
WAV03 INTO PAGE_3A;
WAV02 INTO PAGE_39;
WAV01 INTO PAGE_38;

//.stackstart, /* eventually used for OSEK kernel awareness: Main-Stack Start */
SSTACK, /* allocate stack first to avoid overwriting variables on overflow */
//.stackend, /* eventually used for OSEK kernel awareness: Main-Stack End */
DEFAULT_RAM INTO RAM;
//.vectors INTO OSVECTORS; /* OSEK */
END

Compilator Command line arguments;
-------------------------------------------
-CpPPAGE=RUNTIME -CPUHCS12 -D__NO_FLOAT__ -D_HCS12_SERIALMON -Mb



I wonder what I forgot ?

[CompilerGuru]

This all looks reasonable to me, I did not spot the problem.
So basically this sounds like a task for a debugger.
Are you able to debug the application?
You could also try to debug it in the simulator.
Does the map file look ok?
How do you flash the application? Are the array contents correctly flashed?
Let us know what you find.

Daniel

[kwik]

Thank you for answering ,Daniel !

Since the prm file says

/* banked FLASH ROM */
PAGE_38 = READ_ONLY 0x388000 TO 0x38BFFF;
PAGE_39 = READ_ONLY 0x398000 TO 0x39BFFF;
PAGE_3A = READ_ONLY 0x3A8000 TO 0x3ABFFF;
PAGE_3B = READ_ONLY 0x3B8000 TO 0x3BBFFF;
PAGE_3C = READ_ONLY 0x3C8000 TO 0x3CBFFF;
PAGE_3D = READ_ONLY 0x3D8000 TO 0x3DBFFF;

it is my understanding that we read address 8000 to BFFF ,and
the pageregister set to 38,39 ....3D decide which bank we read.

Sooo , I did MD 8000 8100 in the BDM ,which means dump bytes
from 8000 to 8100 .... its all 0xFF in there.

Is it correct that my WAV01 is expected to be in 8000 ? yes ?

[kwik]

MAP File says ;

.init________72___R_____0xC000____0xC047___ROM_C000
.startData___11___R_____0xC048____0xC052___ROM_C000
.rodata1____104___R_____0xC053____0xC0BA___ROM_C000
.text_______724___R_____0xC0BB____0xC38E___ROM_C000
NON_BANKED___87___R_____0xC38F____0xC3E5___ROM_C000
.copy_________9___R_____0xC3E6____0xC3EE___ROM_C000
WAV02_____13648___R_____0x398000__0x39B54F_PAGE_39
WAV01_____13504___R_____0x388000__0x38B4BF_PAGE_38
.stack______256___R/W___0x3400____0x34FF___RAM
.data_________2___R/W___0x3500____0x3501___RAM

hmmm to bad I cant get the list better looking ....

Message Edited by kwik on 2006-10-1201:16 PM

[CrasyCat]

Hello

  Did you try DB 0x38800..0x388010?

  What is displayed then?

 If you write just DB 0x8000..0x8010, debugger will show content of whatever bank is pointed

 to by PPAGE.

CrasyCat

[CompilerGuru]

>MD 8000 8100 in the BDM

Which debugger is this? And how do you flash the application?
Not an issue if you are using hiwave, but this sounds as if you are using something else.
If you are using the srecords, check that you use an srecord with an address encoding your flasher understands, I think the stationery generates two srecords with the same content but with different addresses. With an adapted *.bbl file you can generate any mapping you need.

Daniel

[kwik]

Hello ;

This is what I get when doing :

S>
D-Bug 12 4.0.0b29
Copyright 1996 - 2005 Freescale Semiconductor

S>MD 388000 388100

8000 FF FF FF FF - FF FF FF FF - FF FF FF FF - FF FF FF FF
8010 FF FF FF FF - FF FF FF FF - FF FF FF FF - FF FF FF FF
8020 FF FF FF FF - FF FF FF FF - FF FF FF FF - FF FF FF FF
8030 FF FF FF FF - FF FF FF FF - FF FF FF FF - FF FF FF FF
8040 FF FF FF FF - FF FF FF FF - FF FF FF FF - FF FF FF FF
8050 FF FF FF FF - FF FF FF FF - FF FF FF FF - FF FF FF FF

So ,the monitor Im talking to ,residing on all Wytec boards ,I believe ,comes from Freescale.

All I do is ;

-Enter

S>fload

And the monitor waits for receiving S-Records on the serial line.
I then sends the S-records ,line by line to Freescale's monitor ,which then burns it into flash.

It all works fine ....the program I burn starts up ,I can see it starting up because lots of my printouts comes on the serial line...

The S-Record is an S2 file ,produced by this command;

sreccvt -m c0000 fffff 32 -of f0000 -o wavplay.s29 HCS12_Serial_Monitor.abs.s19
pause

As you probably know sreccvt is also a Freescale utility ,making ,in
this case s2 records from s1 records....

The S1 file came from Codewarrior....

Message Edited by kwik on 2006-10-1508:34 AM

[kwik]

The general format of an S-record is:

+-------------------//------------------//-----------------------+
| type | count | address | data | checksum |
+-------------------//------------------//-----------------------+

type:A char[2] field. These characters describe the type of record
(S0, S1, S2, S3, S5, S7, S8, or S9).

count:A char[2] field. These characters when paired and interpreted as a hexadecimal value, display the count of remaining character pairs in the record.

Address ; For an S2 record ,its 3 bytes.

I can see that my file starts with

S2 24 0F8000
...so the address is 0f8000 dont know why the address is
0f8000 ,instead of 008000 .... beats me

Then the address inceases upwards ,and the last line starts with
S2 24 0FFFE0

hmmmmm ....very strange ... no 388000 to be seen ....

Also when investigating the s1 output from Codewarrior .....these addresses
are nowere to be seen....

[kwik]

Since I dont know how to make Codewarrior contact Freescales DBug12 on the board,I send the S-records myself to DBug12 ; Line by line.

There is nothing wrong with the sending ,or the burning DBug 12 is doing on the board ...all works fine ; Programs are buurned ,and starts up fine....

But ....its something going on when Codewarrior generate the s-record .... controlled by statements here and there ...making me loose control of the process....

So,since I have no clue of what Codewarrior is doing regarding s-records ...... hmmmm

I see some veeery suspect statements in the so called bbl file ....
like this ;

/* logical non banked flash at $4000 and $C000 to physical */
origin = 0x004000
destination = 0x0F8000
SENDBYTE 1 "%ABS_FILE%"

origin = 0x00C000
destination = 0x0FC000
SENDBYTE 1 "%ABS_FILE%"

Who knows what consequences this has ,and were ...... but the last one,I suspect is what makes it place stuff in 0F8000 .....

[CompilerGuru]

Hi Kwik,

>Who knows what consequences this has ,and were ...... but the last >one,I suspect is what makes it place stuff in 0F8000 .....

No, not for you....

First, there are two address format used.

- banked/logical: basically bits 16..23 are just taken from PPAGE.
e.g. 0x388000. 0x3FBFFF is refering to the same byte as 0xFFFF.

- physical/linear: All the flash content is mapped to a contignious order. In your case, the end is aligned to 0xFFFFF, I think the mapping is derivative specific. 0x0FFFFF is refering to the same byte as 0xFFFF.


Here's the setup for your case:

HCS12_Serial_Monitor.abs: generated by the linker, controlled by the prm file. Uses banked/logical.
HCS12_Serial_Monitor.abs.s19: generated by the burner, burner.bbl, first part only ("logical s-record file"), using 0x388000/banked/logical addresses.
HCS12_Serial_Monitor.abs.phy: generated by the burner, burner.bbl, first part only ("logical s-record file"), using 0x0F8000/physical/linear addresses. This file is generated by the bbl part you copied, but as you are not using this file....

HCS12_Serial_Monitor.abs.s29: generated by the sreccvt. The sreccvt is not part of the standard delivery of CW, it maybe from Freescale, I don't know. It basically does the same thing as the lower part in the bbl, it converts maps the logical/banked addresses to physical/linear ones. You did configure it to read HCS12_Serial_Monitor.abs.s19.

So I suspect that your *.s29 and your *.phy contain are using the same addresses. Right?

Anyway, the question is what kind of addresses does the "DBug12 monitor" expect, again, I dont know.
You can adapt the bbl file to generate any kind of mapping you need, in case non of the three SRecord files you already have does provide the right one. (or maybe you are not using the right options for sreccvt?)

Daniel