MCF52252 start and debug problems

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

MCF52252 start and debug problems

817 Views
marcomaioli
Contributor II

Hi all
We have two board. One with MCF52259 and one with MCF52252.
These board have the same hardware: we are mounted the minimum configuration system:
- power supply;
- clkmode in 48MHz external oscillator;
- deasserted the pins "TEST" and "RCON".

We download the firmware the two micros in the same way, with PE Micro USB ColdFire Multilink.
With MCF52259 we load the file Freescale_52259_1x32x128k.cfp while with MCF52252 we load Freescale_52252_1x32x64k.cfp (downloaded from PE Micro site).
We loaded a little application that initialize the Port C for lights one led. This led is connected at the same pin of this Port on both board. The application is the same, but is builded for the MCF52259, in the first case, for the MCF52252 in the second.
In both case we check that if firmware is loaded (with Verify Module) and all is ok.
When we restarted the boards, there was two different behavior:
- the board with the MCF52259 ligths the led, as programmed;
- the board with the MCF52252 doesn't work.

We have done another test: we have built the application for the MCF52252 and we have loaded it on MCF52259 board. When we restarted the board the leds run correct. We have done that becouse for us is the same core family.

We don't understand why the MCF52252 don't run.

Attached the configuration and the application file

Thaks for support

Best regards
Maioli Marco

Original Attachment has been moved to: usrEntry.txt.zip

Original Attachment has been moved to: Freescale_52259_1x32x128k.CFP.txt.zip

Original Attachment has been moved to: Freescale_52252_1x32x64k.CFP.txt.zip

Labels (1)
0 Kudos
4 Replies

513 Views
soledad
NXP Employee
NXP Employee

Hi Marco,

In my opinion this is a hardware issue. However in order to isolate the issue between hardware and software is it possible that you can swap the devices?

I mean would be possible that you change the MCU from the good board and placed on the failed board, and the failed MCU placed on the good board. This is in order to check if there is any problem with the MCU or with the board.

If the problem is the board you can start to check all the voltages, make a visual inspection looking for solder short, component missing etc.


Regards


Sol

0 Kudos

513 Views
TomE
Specialist II

The MCF52252 has less FLASH and RAM than the MCF52259 does. Make sure you haven't built the code to use the top of the MCF52259 RAM or FLASH, which the other chip doesn't have.

If you've got a debug pod, then why not use it to debug this problem? You should single-step the one that works and then compare with single-stepping the one that doesn't.

Tom

0 Kudos

513 Views
marcomaioli
Contributor II

Hi all,
I have done some test and i Have watched some signals with the oscilloscope in two cases:

- one with the MCF522529 (MCU that works ok)
- one with the MCF52252 (MCU that doesn't work)

I have watched ALLPST signal. I have noted that, with the same software (as I have mentioned in the last post), this signal is '0' on MCF522529, and is '1' on MCF52252...

Why? Why the MCU52252 is in halted state if the software and the hardware are the same?

I have watched also BKPT signal and, in both cases, it remains at logical state '1', so I don't understand what's happen...
Have you got some ideas?

best regards,

Maioli Marco

0 Kudos

513 Views
TomE
Specialist II

Have you checked the RAM and ROM use? Check the MAP file and read the addresses in the HEX file. Post the results of this here together with the expected memory ranges from the Data Sheets.

Have you got a debugger? Have you used it? If you don't have one, get one.

Tom

0 Kudos