USBDM and MC9S08PA4A

cancel
Showing results for 
Search instead for 
Did you mean: 

USBDM and MC9S08PA4A

1,169 Views
Contributor III

Hi,

 

I've got a cheap usbdm from ebay.

When I look inside I can see that it is based on an MC9S08JS16(CWJ).

With CodeWarrior 10.7 on Winsows 7 64 bits.

And the most recent version of the usbdm software and usbdm driver from sourceforge (v.4.12) installed.

 

This setup works fine with an MC9S08QG4 target.

Download, breakpoints, registers, variables, .. everything great.

 

Problem is with an MC9S08PA4AVTG target. Brand new, never programmed before.

Here I get

"Connection with the target has failed. Please cycle power to the target. Retry connection?"

all the time. It never works.

 

I'm using the same target setup (breadboard, bdm connector, etc) for both scenarios,

just switching the the bareboard object images and the target MCUs.

The QG4 works great the PA4A fails miserably.

I've tried with different target power setups, both from CW Debug Configuration

and the board itself (which has dip swiches for 0v, 3v, and 5v) with no luck.

Also with a different PA4A.

 

 

The PA4A is a bargain compared to any MCU out there and I would really like to make it work.

 

Has anybody seen the same problem?

 

Has anybody made a PA4A work in a similar configuration? Or with any chip in the PA/PT family?

 

Has anybody made a PA4A work in a different configuration?

 

 

I appreciate any help or feed-back

Does not have to be long, "Works for me" or similar would be great. 

 

--Thanks,

  Peter Koblauch

 

----------------------------------------------------

A day later:

  I tried the stand-alone HCS08 Flash programmer (no CW),

  Program/version USBDM-JS16-SWD_SER-0001, BDA Firmware Ver 4.12.1, DLL  Ver 4.12.1.130

and the results are similar:

1) when clicking "Detect Chip"

   1) QG4 is detected correctly

   2) for the PA4A I get "Connection with target has failed ... etc"

 

 

----------------------------------------------------

Added Monday Dec 5, 2016

Change:  to subject line to specify processot target type

Also point out that this is a brand new, never-programmed before target chip

Original Attachment has been moved to: usbdm_RESET_CONNECTED.log.zip

Original Attachment has been moved to: Flashprogrammer_RESET_DISCONNECTED.log.zip

Original Attachment has been moved to: Flashprogrammer_RESET_CONNECTED.log.zip

Original Attachment has been moved to: usbdm_RESET_DISCONNECTED.log.zip

0 Kudos
7 Replies

80 Views
Contributor III

Hi pco,

thanks for the nice scope screenshots! That scope's better than mine.

I have attached the log files:

A set with RESET connected and a set with RESET disconnected

and 2 scope shots: for both RESET was connected (only the QG4 worked)

I could not figure out how to attach them here so I did it in the original posting.

--thanks

0 Kudos

80 Views
Senior Contributor V

Hi Peter,

I have received a MC9S08PA4AVWJ and have a built a minimal board to check for differences in the earlier device.

The device ID is different (as expected) but it programs OK with a couple of different version BDMs I tried (JS16 + MK20).  I tested at 5V and 3.3V - It seemed to be more reliable with connected at 5V, or at least, it connected more often without the cycle power prompt.

At this time I can't really think why your setup doesn't work.

One question. 

  • When trying to connect do you receive the prompt to cycle the target power?
  • What result do you get for manually selecting the device type and the doing a mass erase? "Cycle Power" prompt ?

Some comments on the differences between PA4 and QG8 devices:

  • To enter Background mode with the QG8 it is only necessary to hold the BKGD pin low while using the hardware reset, software reset or power-on-reset to reset the device.
  • With the PA4 only a power-on-reset or the software reset will work.
  • This may explain the different results for the two devices.  I would not expect to see the "Cycle Power" prompt as often.
  • The "Cycle power" prompt is sometimes necessary since the software reset method requires at least a partial connection to the device.

You can try to manually do a Power-cycle reset into debug mode by holding the BKGD pin low while turning on the device.  Release background and see if the BDM can communicate.

For reference, the circuit being used for testing

pastedImage_1.pngbye

0 Kudos

80 Views
Contributor III

Thanks a lot for your reply, pgo

It's great that you can communicate with the developer in this forum

I will respond in Part 2 below

But first for the good new

Part 1

---------

 I made a little progress somehow, thank god

My setup used to be with the USBDM programmer connected to target chip in regard to

-Vdd

-Vss

-BDM

-RESET.

Did not seem unreasonable at the time.

No other source of power for the target.

Never worked, until  RESET got disconnected.

Yes, that was it.

"work" here means:  Click the "Detect Chip" in the Target tab of HS08 Programmer widget, and always get a good reply (also after an OS reboot or an USBDM power-cycle or after closing/re-opening the HS08 widget).

Actually "work" does not mean a lot, but just that communication between USBDM and target works for this small feature.

So, omitting the RESET connection solved my problem.

I can't be sure I am there yet. But I kinda guess I am.

I got some hints from reading AN3762 that describes variations in BDM implementation across the HC08 line.

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN3762.pdf 

If I get any new insights or problems I will report to the list of-course.

Part 2

--------

pgo, regarding your reply

Yes, the HCS08 programmers are different. My version has the check-box "Use Hardware Reset" greyed out. No clicking of other check-boxes would enable it. I dunno, perhaps it could have helped.

I don't know what PA4s you tested with, but mine were actually PA4As. According to the datasheet they should be the same, but some HW/firmware problems were fixed in PA4A according to the ERRATAs for the 2 versions . They could have "upgraded" some BDM parts of FW as well. Yes, I don't envy you, pgo. Another HW dependency perhaps to possibly deal with. I may understand you a little (was a  developer in the 90s for a product with support for 7 quite differen Unix implementations, each implementaion had version differences of course). Actually it's not that bad and can be interesting provided you are given the time for it.

Many thanks,

  Peter Kobl

0 Kudos

80 Views
Senior Contributor V

Hi Peter,

Can you run the debug version of the programmer and post the log files please?

(Assuming windows)

C:\Program Files (x86)\pgo\USBDM 4.12.1.150\UsbdmFlashProgrammer-debug.exe -target hcs08

The log files are in %APPDATA%\usbdm:

Flashprogrammer.log

usbdm.log

I will purchase a PA4A and check it when it arrives.

I re-tested with a different USBDM-JS16 that doesn't have the reset pin monitor feature and it programmer OK as well.

pastedImage_13.pngpastedImage_16.png

In regard to the APP note you posted, when the USBDM software displays the "Please cycle power to the target" dialogue it is attempting a power-on-reset into BDM mode as described in section 3.3 SG Family In-Line Programming Summary. This should work with any HCS08 device.

It would also be a good idea to update the BDM firmware as there is a minor revision number not reported by the above.

bye

0 Kudos

80 Views
Contributor III

Hello again,

Thanks for your reply,

Unless you have already ordered, I would be happy to smail you a  PA4A or two (TSSOP-16). You could drop me an email with address to send it to, which I would do this afternoon (from Denmark). Would reach you (is it Scotland?) in about 2 days if postal is effective there. I guess you might want them bare. Also got a couple on a tssop to dip adapter with the most important pin pads brought out. One is "virgin" meaning that it has never been programmed. Bare ones also have never been programmed. Which may make a difference compared to a chip that is a "has been". Or the test case where one has/has not been erased before. And, who knows?

 

I'll take a look at the logging you suggested later today.

Not that important stuff below ---

----------------------------------------------------------------------------------------------------------------------

I did some "logging" myself a couple of days ago with a scope on BDM and RESET.

1) with virgin PA4A

With the original setup: RESET, BDM, Vcc, and Vdd all going to target.

RESET low all the time. You see BDM initially being HI, then it goes HI->LOW and stays low for 1.0ms (almost exactly), then it went LOW->HI and stays there, end of story. So it looks like the USBDM was doing the right thing (it is trying to do a BDM SYNC, isn't it?) and the PA4A did not react at all. So not working: the HCS08 programmer app says "Connection ... failed" etc.

2) with  QG4, not sure if virgin or not

again the original setup: RESET, BDM, Vcc, and Vdd all going to target.

RESET low all the time. You see BDM initially being HI, then it goes HI->LOW and stays low for the 1ms, then a brief  LOW->HI->LOW (about 4uS), which I guess was the speed-up pulse from the USBDM followed by an active pull-down by the target for the specified number of cycles. Then it stays HI for about 0.1ms and then a lot of wiggeling. All in all it looked like an OK SYNC followed by general communication. And the HS08 programmer app also was happy and displayed the chip model/type as expected.

As for the scope results in 2) I initially suspected a bug with SYNC speed-up pulse and that the QG4 was more tolerant than the PA4A in handling something that looked like a protocol violation. I mean the 3-4uS must cover both the speed-up pulse from the USBDM AND the 16 cycles of waiting that the target is supposed to be doing (once it recognizes the HIGH). .... That's pretty fast. .... Another thing that bugged was the apparent lack of "granularity" in the speed-up pulse. The 3-4 uS on the scope (my scope, only Pico 20mHz/200M samples/sec) is composed of a) USBDM goes from pulling BDM LO to pushing it HI as fast as it can and then it relases BDM  + 2) having seen the BDM high, the target waits the number of cycles it is supposed to + c) target pulls BDM down. Between a)  and b) I expected BDM to "slowly" be drifting up because of the taget pull-up resistor. I would have expected a bit of a curve there when you look at it in 10nS samples/granularity.  But I don't. I guess the speed-up really does speed it up a lot. (:-)  ... good.

----------------------------------------------------------------------------------------------------------------------

 

Gotta go, but I'll check this forum and my email during the day. As for the logging that will be tonight.

--regards

0 Kudos

80 Views
Senior Contributor V

Hi Peter,

For reference these are the initial connection waveforms (SWD=BKGD, RST=RESET, CLK not used).

pastedImage_1.png

Blank PA4 - Reset due to watchdog or illegal instruction?

Can't connect.

pastedImage_4.png

Connection after power cycle with BKGD low - SYNC + Background mode activation

pastedImage_2.png

As above - first part zoomed

pastedImage_3.png

As above - second part zoomed

bye

0 Kudos

80 Views
Senior Contributor V

Hi Peter,

I tested a JS16 based USBDM with a MC9S08PA4VWJ and the stand-alone programmer.

I was able to program EEPROM and Flash without any problems.

The test circuit was very minimal (the circuit says QE8 but the same PCB was used with the PA4):

pastedImage_1.png

pastedImage_2.png

This is a slightly later version that was used in your attempt.  This is actually the current version but I would not expect any change as support for the PA4 is quite old.

I did initially get the following dialogue:

pastedImage_3.png

It is necessary to cycle the target power while this dialogue is visible.  This is a limitation (feature) of some of the HCS08 devices.  The BDM can only be activated by a power-on reset with BKGD low.  The reset connection is not necessary.

bye

0 Kudos