USBDM - Version 4.9.4 (JS16/JMxx Hardware Versions)

[pgo]

Dear All,

USBDM has been updated to V4.9.4.

Please post any queries on this version in this thread,

Information available at: SourceForge

bye

Note

• Please note that these design are different from the Freescale OSBDM-JM60 design which was proceeding independently while I was doing the above designs.

BDM History4.9.4 (April 2012) -

• More bug fixes
  • HCS08 programming in Codewarrior 10.1 may fail without warning
  • CFVx command line programming failed
  • Codewarrior 10.x Plugin had obscure bug (hard to describe its effect!)
• Extended reset & power options added to GDI & Programmers
• Programmers
  • Load & Go option added
  • Added check for disk file change and Auto Reload option.
  • Added Smart security option.
  • Deleted Prompt to cycle power option - This was being ignored in most cases anyway   :smileyhappy:
  • Added several command line options corresponding to above.
• Updated documentation

[pgo]

Dear All,

USBDM has been updated to V4.9.4.

Please post any queries on this version in this thread,

Information available at: SourceForge

bye

Note

• Please note that these design are different from the Freescale OSBDM-JM60 design which was proceeding independently while I was doing the above designs.

BDM History4.9.4 (April 2012) -

• More bug fixes
  • HCS08 programming in Codewarrior 10.1 may fail without warning
  • CFVx command line programming failed
  • Codewarrior 10.x Plugin had obscure bug (hard to describe its effect!)
• Extended reset & power options added to GDI & Programmers
• Programmers
  • Load & Go option added
  • Added check for disk file change and Auto Reload option.
  • Added Smart security option.
  • Deleted Prompt to cycle power option - This was being ignored in most cases anyway   :smileyhappy:
  • Added several command line options corresponding to above.
• Updated documentation

[richard1094]

does version 4.9.4b support MC13233C(HCS08QE) ?

I have try , but always get error message when Detect Chip:

Failed to read any ChipIds from target

Reason: Failed to read from target

Thank you.

[pgo]

Richard,

I don't have a MC13233C to test so I can't say for sure if it works with USBDM, however MC9S08QE-QE8, -QE16 & -QE128 have been tested and work.  I have also tested a MC13213 which is a similar idea to the MC13233C I believe.

AFAIK the MC13233C should work.

Have you tested the BDM with another chip?

What is the actual hardware you are using?

bye

[richard1094]

Have you tested the BDM with another chip?

no

What is the actual hardware you are using?

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=RDIMX53SABRETAB

because the BDM &  board(MC13233C)  are new (not tested) , I do not sure BDM hardware or board(MC13233C) are fine.

I will try it with other BDM/board.

thank you.

[Sergik]

Good day!
I installed USBDM 4.9.4b. I need to program 9S08GB60, but the program does not want HCS08_FlashProgrammer open the file with the firmware *. S19. In what may be the problem?

[pgo]

Dear Sergik,

I've tried opening the file using the HCS08 programmer under windows-XP & Win7-32bit and in both cases had no problems.

Can you give more information about your system?

bye

[Sergik]

Dear pgo.

I've been using Win7 32 bit, the problem is exactly.
It is interesting to note that the file, such as Flash Image USBDM_JS16CWJ_V4.sx opens in HCS08_FlashProgrammer.

Maybe the problem is that I use  USBDM_JS16_SOIC20[Minimal]?

[Sergik]

My problem is solved!
The problem was that the path to the firmware contained in the encoded symbols Cyrillic.
Changed encoding to English and it worked.
Good-bye! 

[Sergik]

Dear pgo.

 I use a system of Win7 64-bit, so maybe there is a problem.

I will check on Win 32 bit system on another machine.

[bendjy]

Dear pgo!

After apply the fixes from Your post, the programming of MC9S12DP512 is done without problem.

All work perfectly.

Thank You for amazing work.

USBDM is perfect tool!

bendjy

[carloscuev]

Oh yeah, bug solved in v4.9.4b !

[pgo]

Hi,

I suggest you turn on memory verification in the download to make sure that the error is gone rather than just re-located

Can you post details of the original project so I can verify this. Also what version of USBDM  was displaying the bug?

If it was in V4.9.3 then it is probably the earlier bug that was fixed.

bye

[carloscuev]

Yes it was v4.9.3 what I was using.

I detailed the bug here: At first I thought it was a compiler issue:

https://community.freescale.com/message/109984#109984

What other details can I give you?

I attached CC-BAT12-G2_QB8.abs.GOOD.s19 flashes OK with any version

Also the same code plus one extra line compiles the other attached CC-BAT12-G2_QB8.abs.BAD.s19 that flashed from Eclipse leads to bad flashing, and flashing from standalone tool flashed well. (of course only using v4.9.3)

[carloscuev]

Hello pgo, I installed back v4.9.3 to flash target and dump the whole memory. 

1. What Should be flashed.s19 - As its name states is the binary generated by CW

2. TARGET_MEMDUMP_BAD_USBDM_v4.9.3.s19 - Dump from entire memory of a real target (0x0000 to 0xFFFF) when flashed bad from USBDM v4.9.3 plugin

3. TARGET_MEMDUMP_GOOD_USBDM_v4.9.4b.s19 - Dump from entire memory of a real target (0x0000 to 0xFFFF) when flashed good from USBDM v4.9.4b plugin, it should be the same as "What Should be flashed.s19" in the Flash area. Also note that in this project the first sector of flash memory (0xE000 to 0xE200) is erased and written in execution time, (for configuration, serial number, etc.), so they may differ.

 UPDATE: Started analyzing mem-dumps and noticed this:

First difference is the block from 0xE2B8 to 0xE36B

The bad dump takes the data from:
0xF2B8 to 0xF36B
and writes it to
0xE2B8 to 0xE36B

And what happens then to 0xF2B8 - 0xF36B?
Is filled with 0xFF

[pgo]

Hi,

Thanks for doing this.  It would appear to be the bug that was introduced in 4.9.3 (I think) and fixed in 4.9.4.

The transfer of large blocks of data from the GDI (Codewarrior) to the programmer had a bug.

I'm sorry that it tied up so much of your time.

bye

[carloscuev]

No problem pgo, I'm glad it was resolved ! And learned a lot of things I would not have learned otherwise !

Thank you for your hard work in this project, I really like my usbdm

[bendjy]

Hi  pgo!

I use CW to program the MC9S12DP512 chip with our s19 file without problems ( HW is JS16 ).

i try to program the same chip with standalone programmer without success.

I make the debug log files for two ways - with CW and with standalone programmer and post here in zip.

With MC9S12DG256 and apropriate s19 on the another board all is OK.

I do not understand where is the problem.

10x for the great work!

bendjy

[pgo]

Dear Bendjy,

I don't have a MC9S12DP512 to test with but I believe I have found the problem,  I had overlooked the different block sizes on the 512K chips in that family.

Could you try the changes in the attached file and let me know if they work?

bye

[bendjy]

Dear pgo!

Thank You for the fast reply.

I will try this solution tomorow in the office and will give feedback.

bendjy

[carloscuev]

I think I have experienced the osbcure bug, I was progamming happily in CW v10.2 and added an extra line of code, it didn't flashed correctly.

It is writing to the flash address:

0xE31A

the contents that should be in:

0xF31A

making the CPU go insane :3

Flashing with standalone tool flashed resulted in well written flash !  I spent 5 hours finding the cause.

Am I right or I have discovered another obscure bug?