PGO - USBDM - MC9S08PB16

[ricardotrevisan]

Hi PGO,

A few months ago, I needed to debug MC9S08PB16, which was not supported on USBDM. We use Luciano's USBDM.

I changed some files and created a new HCS08-PBxx-Flash Program. These files and sources are attached. The Codewarrior worked pretty well with these patches on USBDM, and it allowed me to build a new firmware for one new product.

However, last week, production started, and USBDMs were not able to program the flash of most production Microcontrollers except for a few.

I attached the error logs, along with some oscilloscope images of BKGD  (yellow) and BKGD/SWDIO_DRV USBDM internal (Blue).

Even more, for some unknown reason, we got a Sawtooth wave a couple of times. I cannot tell if they have a correlation with the programming issue. It can be seen in the Sawtooth.jpg.

I will be grateful for any help you could, and feel free to ask for further data.

Best,

Ricardo Trevisan

[pgo]

A follow-up
I have looked at the actual log and the TCL file provided.

It appears to be connecting OK and then failing. Maybe the COP.
The TCL appears to be based on the PT device (at a guess). It is not correct. The PT and PB are significantly different (WDOG vs COP).

The PB has a WCOP that should be disabled through the SYS_SOPT5[COPT] (RM section 26.4 etc). Refer to the default script for an example.

I haven't looked at the flash code but presumably you have and since it seems to program OK sometimes I guess its OK.

bye

[pgo]

Hi,

I have received some sample devices and done some initial tests but have not yet looked at actual programming the flash (apart from Mass erase).

As expected, it is not possible to reliably program these devices if they are blank.  A mass erased device will enter a reset loop from power-up that interferes with connecting using the SYNC sequence. Refer Initial Connect Image.

It is necessary to hold BKGD low while powering on the device to obtain a reliable connection.  As explained in Section 27.1.1 Forcing active background of the PB16 manual.

If you do the above, it is then possible to mass erase and temporarily disable security on the device using the ERASE_VERIFY flash command.  This only persists until the next reset.  The last point is important as if the watchdog is still active then the device will be secured again after a short while.  It is necessary to disable the watchdog before doing the mass erase.  This is possible even on a secured device.

Anyway I will have a look at the programming shortly.

Attached is the HCS08-PBxx-flash-scripts.tcl I have been using with UsbdmScript for initial testing.

[pgo]

Hi,

I have uploaded a new version with support for MC9S08PB16.

https://sourceforge.net/projects/usbdm/files/Version%204.12.1/Software/

Files have also been updated on GITHUB.

This version will still have the problem that the initial connection may need power to be cycled while BKGD is help.  The programmer will prompt the user to do this.

There is no solution to this problem unless the BDM has the ability to control the target power.

bye

[ricardotrevisan]

Hi pgo,

I forgot to explain that there is more than one type of error showing.

Now, I am attaching three more logs of the same issue with different error messages.

Best Regards,

Ricardo Trevisan

[pgo]

Hi Ricardo,

I have not looked at this in detail so just a quick response:

9S08 devices can only be programmed if the target can be forced into active background mode.

There are several ways of doing this:

1. Holding RESET Low during power-on-reset
2. Diving BKGD low immediately after a serial background command that writes a one to the BDFR bit in the SBDFR register
3. Some devices may be forced by RESET+BKGD

Note that holding BKGD pin low during other resets may not result in active background mode on many later chips.  I suspect this was a design choice motivated by reliability in target applications where the BKGD pin may have been used for the application and so could not be guaranteed to be high during reset.  In addition the RESET pin may itself be re-purposed.

Unfortunately, on some devices only the 1st method will work reliably.  This is for several reasons:

• The BKGD pin may be allocated to some other function very quickly after reset
• The chip may be stuck in a reset loop due to COP time-out, Illegal instruction execution or grossly misconfigured clock.

If either of the above is true, then the USBDM module may not have time to apply the second method between resets.  If the programming software can detect this it may prompt the user to manually cycle Vdd while the BDM will hold BKGD low.

So, unless the actual USBDM programmer you are using supports target power control it cannot be reliably used for production programming (without human intervention).

The sawtooth pattern (I presume on reset pin) would indicate that this is the problem.

I don't think I have PB chip to play with so I unsure what I can do to investigate but I will check through the information you have provided to see if it indicates anything else.

Some thing to try (mainly to diagnose rather than solve):

• Manually wire BKGD to Gnd while applying power. 
• Then try programming.
• After programming once (with a sensible program) confirm that the chip is now reliably programmable.

If the above works the reason if likely confirmed to be as described.

bye

[ricardotrevisan]

Hi pgo,

Thank you very much for your time.

I guess the issue is driven by other reason. Take a look at summary:

1- I changed the flash code to fit PB. I suppose I did it correctly once I debugged the firmware for weeks.

2- The correct connection was assured once every single time we did a "detect chip" and "mass erase" both successfully.

3- Some chips didn't accept the program, and others did.

4- The chip that refuses to be programmed will fail 99.9% of tries, not 100%.

5- Some chips can be programmed 100% of tries at that same chip.

6—The same USBDM can program all chips (100%) using the Codewarrior to flash the same S19.

Maybe this info could help to solve the issue.

The best,

Ricardo

[pgo]

Hi Ricardo,

Did you read my second reply - AFAIKS  you have not disable the COP in the TCL scripts?  In theory it should be sufficient to do so in the programming code but as was done for PT chips. For other chips the COP was disabled in TCL.  There may be some reason for this but I can't recall it.  I suggest you add code to do so.

The programming of chips in Codewarrior (depends on version) uses it own algorithms so may not be relevant.

There are a few things that look strange:

1. Unneeded disable EEPROM using non-existent NVM_EEPROT register @0x3028
2. configureICS_Clock() routine appears to be using an address of 0 for the clock.  I have no idea where that is coming from.

At the moment I can't see how to progress this without a chip to test.

I will see if NXP will supply a sample.

bye

[ricardotrevisan]

Hi pgo,

Thank you for your time and tips.

I changed the flash program and TCL to disable WDog instead of refreshing it (attached).

I got no success.

Once some batch of PB micro allow to flash and others batch doesn't, I ask to kindly send your address to my email ric.eedh.br@gmail.com, so I can send you bad samples.

Best regards,

Ricardo

[ricardotrevisan]

Hi pgo,

I would like to add some information that I believe will lead you to a solution.

I told some MC9S08PB16 can be flashed, others don't.

I got a not-worked on and warmed it, and then it worked too.

Please take a look on attached spreadsheet that I compare the cold and hot logs, and marked on yellow, some differences I guess will help.

Also attached the full logs and others files.

I hope it can help.

Best,

Ricardo

[pgo]

The first change reflects a change in the Chip clock speed. The nice round number of 16MHz indicates that the chip did a non-special mode reset and loaded the factory set clock trim value. The odd number is the untrimmed clock speed after a special-mode reset. This is just a fluke.
The second change just shows the connection is unreliable and the write failed. For example a reset occurred between the initial connect and the write operation etc.
I think this just reflects the limitations of the BDM without a power control feature.

[pgo]

Hi,

I have received some sample chips from NXP and will be able to play with these in a few days.

I'm sorry I've been a bit busy lately.

I will PM an address if you want to send some samples that "reliably" fail.

bye

[ricardotrevisan]

Hi Pgo,

Did you have the chance to take a look at the NXP samples?

Ricardo.

[pgo]

Yes - see posting from about 6 hours ago !

[ricardotrevisan]

HI pgo,

I really appreciated your time.

Unfortunately, the issue was not eliminated at all, but it is stable now on the same error: "Target SYNC timeout" that occur on Mass Erase or Program Flash.

Attached we have the Log files.

If it helps the chip marking is: PB16 - MMTJ - XANKA

Best regards,

Ricado

[pgo]

Hi,

It appears to be losing the connection after a software reset to special mode.

Have you updated the BDM firmware?

bye