S08MM128 not running without debugger

[markelson]

Hi,

I have a curious problem with an MM128 not running without the debugger connected. I've seen the other posts that talk about COP etc and that is not the cause. I have found a "fix" by changing the prm file but I don't know why it works. I started with the default prm that gets created when the MM128 MCU is selected. I just changed the memory range that the CRC calc is performed over to just look at the unbanked ROM (as that is where my code resides and it means I can work with 16-bit pointers in my code that verifies the ROM CRC as part of a power-on self-test).

CHECKSUM

    CHECKSUM_ENTRY

        METHOD_CRC_CCITT

        INIT    0x8D9D

        OF      READ_ONLY   0x040B2 TO 0x07FFF

        OF      READ_ONLY   0x0C000 TO 0x0FF9D

        OF      READ_ONLY   0x0FFC0 TO 0x0FFFF

        INTO    READ_ONLY   0xFFB8 SIZE 2

        UNDEFINED 0xff

    END

END

I then find that my application does not run without the debugger connected. I think the MCU keeps resetting (I put some light LED code in right after the stack pointer init) it does not get as far as that without running in the debugger.

By trial and error I found that reverting back to the default checksum prm entry (below) the application will run without the debugger.

CHECKSUM

    CHECKSUM_ENTRY

        METHOD_CRC_CCITT

        INIT    0x8D9D

        OF      READ_ONLY   0x009000 TO 0x00BFFF

        OF      READ_ONLY   0x018000 TO 0x0180B1

        OF      READ_ONLY   0x040B2 TO 0x07FFF

        OF      READ_ONLY   0x028000 TO 0x02BFFF

        OF      READ_ONLY   0x0C000 TO 0x0FF73

        OF      READ_ONLY   0x0FF80 TO 0x0FF9F

        OF      READ_ONLY   0x0FFC0 TO 0x0FFFF

        OF      READ_ONLY   0x048000 TO 0x04BFFF

        OF      READ_ONLY   0x058000 TO 0x05BFFF

        OF      READ_ONLY   0x068000 TO 0x06BFFF

        OF      READ_ONLY   0x078000 TO 0x07BFFF

        INTO    READ_ONLY   0xFFB8 SIZE 2

        UNDEFINED 0xff

    END

END

I am baffled as to why this should have an effect. Does any one know why this should be so or is it more likely that there is some side-effect that is producing the symptoms?

Any ideas gratefully received, Mark

[evgenik]

Hi Mark.

May be the problem in the different place. Can you check when you press on Debug button, into the "P&E Connection Manager" window when debugger start connect to your MCU, into "Cyclone Pro Power Control" section checkbox "Provide power to target" (support voltage to your MCU through your debugger 3.3V or 5.0V, if you have this one P&E Debugger)? May be the voltage to your MCU go through debugger only?

Evgeni.

[markelson]

Hi Evgeni,

That is not the issue. I've isolated it to that the only difference in the s-record that runs and the one that doesn't is the CRC value at one address and which isn't used in the rest of the application. I'm not using P&E kit as the tower kit has it's own OSBDM debugger.

Regards,

Mark

[CompilerGuru]

How does it behave when you uncomment the test for the checksum in the code? Same behavior for both cases?

How are the 2 apps different? You could compare the srecords, if the above prm changes are the only difference, then

only the 2 bytes at FFB8 should be different (well and the checksum at the end of that line).

But actually the code computing the checksums at runtime has to be different as well as with this method of checksum computation, code has to know the set of areas to compute the checksum over as well, so I would think that is different as well.

So maybe the difference in behavior is that the working version just starts slower as it has to compute the CRC over more memory with 24 bit pointers.

Daniel

[markelson]

Hi Daniel,

I can confirm that the only difference in the srecords is the 2 bytes of checksum at FFB8. When the checksum is that computed over the limited range (1st one in my 1st email) the MCU does not run without the debugger (FSL OS BDM on Tower kit). It does run when the checksum is that computed over the 2nd range in my first email.

Mark

[markelson]

Hi Daniel,

Any idea as to how a different checksum value at FFB8 (that is then not used currently in the application) could make the difference as to whether the MCU runs without the debugger?

Mark

[CompilerGuru]

Is FFB8 magical/ a register with some functionality? I saw that this address is listed as a checksum register in the ref manual, but I did not see any additional documentation those registers/addresses. I guess it is just plain flash, or?

In the non working version, can you instrument the code to toggle a bit or insert some other debug patch?

[markelson]

FFB8 is a nonvolatile flash register. AFAIK, it has no functionality other than it is nominated for holding a 16-bit CRC value that can then be used in the application. I can find no reference in the RM to it being used by the MCU. I had previously inserted some code to light an LED right at the beginning of the startup code. This ran and worked with the debugger connected but not without. So it seems the MCU is not running as far as the startup code.

[markelson]

It looks like it may be that FFB8 is used in the determination of whether to enter bootloader or user mode (although the RM does not make this explicit). This might explain why the MCU doesn't run. There is a checksum bypass location that I can set and try this out.

[markelson]

Got to the bottom of this. By experimenting I found that FFB8 is used to determine the MCU mode of operation. Section 3.3 of the RM discusses this but uses different mnemonics to the NV register descriptions in 4.2. 3.3 also gives a misleading description of the memory range checked (1000:FB00) when in fact it seems to be the whole flash array. Hence, I did not link FFB8 as being the same checksum that was used in the mode determination.

My problems arose because I was trying to check just that portion of flash that I was using. Hence, the checksum generated by my prm did not match the checksum calculated by the MCU. The MCU checking can be turned off by setting FFBA to 0:

const byte CHKSBYP_INIT @0x0000FFBA = 0x00;

Thank you for all the replies. I'll close this thread now.

[Monica]

Hey there Mark!

Glad to see you're progressing on that...does this means that the problem has been figured out?

Regards!

[markelson]

Hi Monica,

Unfortunately, I've been distracted by other stuff so I haven't been able to bottom this out.

I'm still scratching my head as to why a different value in the CRC location in the s-record should make the difference between running with or without the debugger. There's nothing in the startup code that would be affected by this - just the boilerplate init SP and init RAM functions. I'll come back to it soon.

Regards,

Mark

[markelson]

Hi Daniel,

The behaviour is the same with or without the checksum code. In fact, I did not change the ranges being checked by the code (just in the prm). In the code, I just altered the return calculation to always return a "pass". I will do some more testing with minimal changes and compared the srecords as you say.

Thank you,

Mark