USBDM - Version 4.9.4 (JS16/JMxx Hardware Versions)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USBDM - Version 4.9.4 (JS16/JMxx Hardware Versions)

9,759 Views
pgo
Senior Contributor V

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


Tags (2)
0 Kudos
39 Replies

1,007 Views
richard1094
Contributor III

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.

0 Kudos

1,007 Views
pgo
Senior Contributor V

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

 

 

0 Kudos

1,007 Views
richard1094
Contributor III

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.

 

 

 

0 Kudos

1,007 Views
Sergik
Contributor I

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?

 

 

0 Kudos

1,007 Views
pgo
Senior Contributor V

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

 

 

0 Kudos

1,007 Views
Sergik
Contributor I

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]?


0 Kudos

1,007 Views
Sergik
Contributor I

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! 

0 Kudos

1,007 Views
Sergik
Contributor I

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.

 

0 Kudos

1,007 Views
bendjy
Contributor I

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

0 Kudos

1,007 Views
carloscuev
Contributor V

Oh yeah, bug solved in v4.9.4b !

0 Kudos

1,007 Views
pgo
Senior Contributor V

Hi,

 

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

 

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

0 Kudos

1,007 Views
carloscuev
Contributor V

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)

 

 

0 Kudos

1,007 Views
carloscuev
Contributor V

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.s19Dump 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

0 Kudos

1,007 Views
pgo
Senior Contributor V

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

0 Kudos

1,007 Views
carloscuev
Contributor V

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 :smileyvery-happy:

0 Kudos

1,007 Views
bendjy
Contributor I

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

 

0 Kudos

1,007 Views
pgo
Senior Contributor V

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

0 Kudos

1,007 Views
bendjy
Contributor I

Dear pgo!

 

Thank You for the fast reply.

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

 

 

bendjy

0 Kudos

1,007 Views
carloscuev
Contributor V

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?

0 Kudos