topic Re: 56F8165 - 0x0200 program address boundary crash (help request) in Other NXP Products

56F8165 - 0x0200 program address boundary crash (help request)

marchesi — Tue, 19 Dec 2006 02:19:40 GMT

(CodeWarrior 7.3 / 56F8165 / WinXP SP2 / PExpert 2.97, in use)

Hello,

When the code downloaded is shorter than 0x200, everything goes fine. With a bigger program the soft crashes.
Using the debugger in mixed view, we can see that where it was expect opcodes, there is now only 0xFF (as the memory was never written...) - screenshot attached.
This happens always and exactly from program memory address 0x0200 and beyond (a page boundary). But it doesn't last forever: if we start the program in higher memory regions, everything runs ok. Other words, there are some specific memory regions where this problem occurs.
First we have tested 2 sample chips, the behaviour was the same. After that, we carried out the test with other 3 'buyed' 8165, and the problem persisted.
When running the code with a 8145 over the same board, everything goes ok.
We have screen shots and test codes to better illustrate the issue, if it's needed.
Thanks,
Marchesi.
p.s. We're having this trouble for a long time, and our project timeline is going to deadline... any tips would help a lot...

Re: 56F8165 - 0x0200 program address boundary crash (help request)

marchesi — Wed, 10 Jan 2007 00:43:24 GMT

Hello,

this is a status update to the problem, since its solution has advanced but it´s not
done yet.

When this option is UNchecked,

Debugger > debugger options > stop on application launch

the program runs ok. It can´t be debugged, though, because if we do a 'run to cursor',
for instance, my friend 0xFFFF appears again at 0x0200 and beyond... (This positions
appears red coded, as if they were changed from the first download).

Well, this is the status so far. But I've found another detail.

The hfmclkd parameter in the .cfg file (flash initialization file) is set
to 0x0A and is meant to be fixed. But how is that, since the clock divider depends
upon the crystal frequency, which can change for each design?

In this problem, the FMCLKD generated by the Processor Expert is 61 (0x3d). As you know,
this is a very important gap from 0x0A, because the slim frequency range of the
flash timing control clock (150kHz~200kHz)...

I feel that the solution could be floating around these waters, but I can´t figure it
out yet...

I believe I´m surely missing something. Any help is welcome...

Thanks again,
Marchesi

marchesi wrote:
(CodeWarrior 7.3 / 56F8165 / WinXP SP2 / PExpert 2.97, in use)

Hello,

When the code downloaded is shorter than 0x200, everything goes fine. With a bigger program the soft crashes.
Using the debugger in mixed view, we can see that where it was expect opcodes, there is now only 0xFF (as the memory was never written...) - screenshot attached.
This happens always and exactly from program memory address 0x0200 and beyond (a page boundary). But it doesn't last forever: if we start the program in higher memory regions, everything runs ok. Other words, there are some specific memory regions where this problem occurs.
First we have tested 2 sample chips, the behaviour was the same. After that, we carried out the test with other 3 'buyed' 8165, and the problem persisted.
When running the code with a 8145 over the same board, everything goes ok.
We have screen shots and test codes to better illustrate the issue, if it's needed.
Thanks,
Marchesi.
p.s. We're having this trouble for a long time, and our project timeline is going to deadline... any tips would help a lot...

Re: 56F8165 - 0x0200 program address boundary crash - solved

marchesi — Fri, 12 Jan 2007 00:14:02 GMT

The initialization of the program flash was replaced on the 8165 .cfg file.

The test code and the project itself now appears to be both running ok.

Since I've not changed anything in the original file before, it could indicate
a CW bug.

Cheers,
Marchesi