S12XE programming issue

[mroczeks]

Hi All,

Notoriously I face programming problems with S12XE devices (mostly XEG128 and XET256, sometimes with XEP100).

Frequently I get HiWave error messages (see attachments) every time I want to reprogram flash with PE Micro USB Multilink Interface. 

I have to Unsecure my device every time I face this problem (so quite frequently). Then loading application (abs file) works OK for a single time.

HiWave version 6.1 Build 10221

Code Warrior version 5.9.0 Build 5294

Microsoft Windows 7 64bit

[kef]

Is contents of NVPROT, NVSEC or backdoor access key defined in your code? If so, then do you have FLASH NOUNSECURE line in multilink preload.cmd file? Without this line debugger may try to write to NVSEC twice, which may make ECC fail and automatically secure your MCU.

FF10..10110 in your first picture makes me wondering if your code defines something at nonexisting addresses 0x10000 to 0x10110. Is it just confusing debugger behaviour?

[mroczeks]

Hi Kef,

None of NVPROT, NVSEC or backdoor key are defined in the code. The issue is somehow closely related to PCB. I may have no problems at all with some board and permanent problem with some other particular board. The case is that everything works if I first perform Unsecure procedure before flashing. 

My code is not defining any stuff at FF10... addresses.

It is not a critical problem but becomes quite irritating if you debug alot during a day.

I discovered that apart P&E_Multilink_USB_Erase_unsecure_hcs12xe file all other command files are empty...

[kef]

Certainly your code defines interrupt vectors at 0xFF10.. The question is why you vectors table doesn't stop at 0xFFFF and continues further into the weeds. I think it must be missing #pragma CODE_SEG DEFAULT or #pragma CONST_SEG DEFAULT after your interrupts vectors table.

I used only XEP100, no smaller variants, but don't remember I saw something like you see. Had to unsecure only when intentionally secured, or due to ECC errors caused by CW reprogramming NVSEC, which was solved adding FLASH NOUNSECURE to multilink ??_preload.cmd file.

[mroczeks]

It is not a problem of code. We have several PE Micro's USB Multilink programming interfaces and programming is successful on some and unsuccessful on others (sometimes really random, like there are some working OK on some of our computers and some others working OK on some other computers). One thing that we discovered is that it helps sometimes when Delay after Reset and before communicating to the target option in Reset Options is set to arbitrary value of 100 ms:

(see attachment)

We have all our programming interfaces updated to the latest firmware and Windows drivers updated - no change.

It has gone so far that we started labeling our interfaces with tags like Suspected, Not working, To be checked... and so on. Sounds funny but the problem is annoying. Sometimes I have to ask a colleague to exchange with interfaces because I know his will work on my computer and mine will work on his computer, and not the other way round.

[kef]

Is RESET pin pulled up with few kOhm resistor? Is ther no excessive capacitance at RESET pin? If both are OK, then you should file service request, also ask P&Emicro for support.

[mroczeks]

Reset pin is pulled up with 10 kOhm resistor. 10nF capacitance connected between Reset pin and ground.