Bruno Marchesi

56800E CW erratic behaviour between flash page boundaries

Discussion created by Bruno Marchesi on Jan 10, 2007
Latest reply on Jan 11, 2007 by Bruno Marchesi
Hello,

This is the test code I'm trying to run:

for( ; ; ) {

led1_NegVal( );
led2_NegVal( );
led3_NegVal( );
led4_NegVal( );
led5_NegVal( );
led6_NegVal( );


}
}

For a long time I'm trying to fix the following problem: when the codes cross a page boundary, 0x0200 for instance, strange things happen. So, to show that up, I've changed the PExpert 0xAC start code address to 0x1AC. This way this code will cross the 0x0200 address.

Then, if we keep the factory setting:
debugger>debugger settings>stop on application launch/default language entry point

the program just crashes. If I make a stop and try a program mem dump, opcodes below 0x0200 turn to FFFF.

if we change that option to:
debugger>debugger settings>stop on application launch/program entry point
it runs ok, and software breakpoints work fine. But that's just because the for loop
resides ahead the 0x0200 boundary. A mem dump shows FFFF again below 0x0200, where
some opcodes were expected.

I believe it's important to say that all original configs were maintained. That is,
the code is just that you see; no .cfg flash initialization changes; no alt-F7 parameters
changed.

Since I'm not using an evaluation board, could some short circuit between pins do something like this?

The 56F8365 data sheet, page 44, table 4-7 says that the program flash has a 1024x16 bits
page size. But the CW .cfg initialization file uses 512 as pageSize parameter. Is that
byte/word respectively?

Something that still bugs my mind is why the set_hfmclkd parameter in the .cfg file is
set and fixed to 0x0A while the PExpert (correctly, it seems) calculates the FMCLKD as 61 (0x3d)... Which one CW picks to make the flash programming?

Thanks,
Marchesi

part: MC56F8165VFGE
CW 56800/E 7.3 - IDE version 5.6.1.1658
PExpert 2.97 - IDE version 3.74 L2
WinXP - SP2

Outcomes