CANNOT PROGRAM RS08KA2 WITH USBDM

BooleanBob · ‎03-24-2023

I have deleted my previous post about this same subject because I have been working on it a little further and found a couple of interesting issues, so I will post my problem again but in a different way and new data.

I will make it as short as possible. I have been using @pgo USBDM open source project for a couple of years now for development and also for teaching. My students have the USBDM project full featured PCB and I ordered about 50 pcs of this board, that uses MC9S08JM60CLD chip. The complete project @ pgo can be found here.

I have the latest USBDM versión installed USBDM_4_12_1_295_Win in my Windows 10 PC. I am using CodeWarrior 11.1

I have 3 completely assembled working USBDM boards, one of which I’ve been using for more than 2 years, programming and debugging most of the time MC9S08 chips e.g. AC60, JM60, QE128, SH8, QE8, PT16, and the like. I kept the other 2 as spares. Never had a problem.

This first PCB's firmware was programmed using another USBDM programmer, and the corresponding FLASH image was used, the one that was available by that time.

I also have an old P&E Micro Multilink cable 12E that I kept as a spare and also for a project in which I used RS08KA2, a tiny chip that was ideal for my project. Never had a problem.

Two weeks ago I couldn't make my USBDM programmer flash any of the KA2 chips from a bunch of about 20 fresh units. I still keep about 150 brand new chips obtained from Mouser. For some reason the programming session starts but it stops at a certain point of the process. After that, it reports that it has erased the chip's memory. Then the programming process crashes and there is no way to regain control. The opened project must be closed an exit CodeWarrior.

I attached the error windows in the pictures. I decided to reinstall the complete USBDM_4_12_1_295_Win in my PC. Again the USBDM board can program and debug any kind of chip, except for my KA2s.

I picked both spare USBDM assembled boards and plug them to see if I had some hardware problem. None of these 2 boards could now connect to CodeWarrior. Both LEDs off. So I decided to reflash the firmware with the corresponding flash image that came with USBDM_4_12_1_295_Win version as along time has passed and the fiemware version needed to be updated.

For this, I used the standalone USBDM HCS08 programmer and my original USBDM programmer working board. Both chips programmed and verified correctly but couldn't connect to CodeWarrior, with the green LEDs off. I tried but couldn't succesfully program several KA2 chips with the RS08 standalone programmer software.

At that point I tried instead to program the two JM60 USBDM boards using the internal CodeWarrior 11.1 flash programmer and had success. Both boards are working normally.

I tried to use the same method with the KA2, but it still has the same problem. It gets stucked before the programming attempt. I tried using the 3 USBDM working programmer boards with no luck.

So, my first conclusion is that there is something wrong with the standalone USBDM flash programmer that reports good programming and verifying but any of the boards worked. This could be solved using the CodeWarrior internal flash programmer version. I prefer to think that I am skipping something.

In the case of the RS08KA2, it is still impossible to program any of the several parts I have using both the CodeWarrior internal flash programmer and the standalone USBDM RS08 programmer. This is very strange because the old P&E Micro 12E Multilink cable can do the job.

Maybe @pgo or somebody could give me a hand and help me understand what I am doing wrong?

I would very much appreciate that.

Thank you.

pgo · ‎03-30-2023

Dear Bob

I have uploaded a version of USBDM with very minor fixes for RS08.

Please test with this version.

Uninstall the previous version first.

Update the BDM firmware using the stand-alone HCS08 programmer using Image as the security option.

Please test:

Try programming and verifying using the stand-alone programmer. Please report the BDM Firmware Ver and DLL Ver from the first tab of the Flash Programmer.
Create a new project in Codewarrior for a RS08 target and check that the you can program and debug using the standard setup.
If you are familiar with using Codewarrior as a programmer (without debugging) , test the programming function.
See if you still have problems as you previously reported. If so please post an exported Codewarrior project that I can try.

Thanks

BooleanBob · ‎03-31-2023

Dear PGO and community friends,

Trying to provide you with as much information I can about this issue, this is what I could do by now.

1. unistalled USBDM_4_12_1_295_Win. I wrongly reported before that the uninstall process crashed, and this time I decided to wait, and to my surprise, after 1 hour and 23 minutes wait, the program finished uninstalling "normally". From my experience, just a couple of versions have this problem, but this can surely be a Windows problem (among many others).

2. succesfully installed USBDM_4_12_1_305_Win, and even without reflashing my USBDM boards that still have the USBDM_4_12_1_295 flash image, I could perfectly program and debug my S08 projects with different family chips QE128, PA16, SH8, QE8, AC60, JM60, etc.

3. using my old P&E Micro 12E Multilink cable (red color plastic case) I could also program and debug my RS08 chips from CodeWarrior 11.1

4. when I reflashed my first USBDM_CF_JMxxCLD_V3 programmer board with flash image USBDM_CF_SER_JMxxCLD_V4.sx matching the USBDM_4_12_1_305_Win version, plugged the board to USB and it is not recognized, as the green LED remains off. Tested in 2 of my 3 USBDM boards.

5. all the tests performed including the attempts to program and debug the RS08KA2 chips have been made with USBDM_4_12_1_295 flash image and USBDM_4_12_1_305_Win in my PC.

6. attached is a single .ZIP compressed file containing several directories with pictures and other information of the different tests, including a working CodeWarrior 11.1 project that programs and debugs with the P&E Micro Multilink tool. Details of the DLL version, etc. are also there.

Unless I could flash my boards with a matching image version, I doubt that the results I can offer could be of much help. The attacment contains the test over CodeWarrior built in FLASH programmer, the standard programmer / debugger, and the USBDM standalone external RS08 programmer.

Reflashing of the USBDM programmer boards have been also made with the USBDM_4_12_1_295 flash image that connects to CodeWarrior and turns on the green and red LEDs.

I am eager to make further test for helping @pgo to try solving this issue.

Thank you !

pgo · ‎04-01-2023

Hi,

I won't be able to look at this for a few days.

In the mean time could I ask you to check Device Manager in windows and see if there is a device reported at all when use your BDM with the failing USBDM_4_12_1_305_Win flash version. For reference, I have attached what is seen in Windows VM under Linux.

I will have to have a another look for the same hardware version for proper testing.

Thanks

BooleanBob · ‎04-01-2023

Dear PGO,

Thank you for your reply.

I have to repair an error in my last post, I am sorry for that.

In one of your previous posts you said:

"Update the BDM firmware using the stand-alone HCS08 programmer using Image as the security option."

And I skipped this important detail. After correcting this, all of my USBDM programmer boards are working well, so they match the USBDM_4_12_1_305_Win version

After your advice, I checked the Device Manager in windows, and this is what it shows. Seems to be OK. Along many installations of USBDM in Windows, I have seen many "flavors" of the way USBDM is shown in the Device Manager window. I can't really tell why this happens and which of the different shown formats is the right one. Anyway everything seems to work fine.

A new compressed .ZIP file is now being attached where you can find a few new snapshots, pictures and console screen log texts that perhaps you may find interesting for diagnosing.

After programming several KA2's again using all of the programmer alternatives, there is just one that starts and ends a complete programming session. This is the CW 11.1 internal programmer (not debbugger) but it still throws a failed blank check at the end, that seems to be irrelevant at that point of the process, because the part is not supposed to be blank after programming, Anyway chips that didn't work after the CW programmer attempt, have programmed correctly, debugged and also ran fine using the P&E Micro tool, so the chips are all healthy.

The other methods including the USBDM external standalone RS08 programmer, are at the moment not working fine. But I am sure that you will finally win !

I can wait, don't worry. As long as I can use my old Multilink cable, I'm happy. But I am sure that this will not be for ever.

Take care!

pgo · ‎04-01-2023

Hi Bob,

I forgot - The device will appear twice:

Once as serial device supporting communication with the target (the image you posted shows this.)
It should also appear as a Debugging Interface as shown in my post.

The second of these is the important one for debugging.

bye

BooleanBob · ‎04-04-2023

Dear PGO, sorry for the delay but the community not always sends an email when replies arrive in.

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

"I forgot - The device will appear twice:

Once as serial device supporting communication with the target (the image you posted shows this.)
It should also appear as a Debugging Interface as shown in my post.

The second of these is the important one for debugging."

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

The second.... well ... it doesn't.

Instead, it appears as a COM port (COM20 in this case as the picture shows)

But this is a veeeery old issue. I have sometimes used the Zadig solution, but I know that you don't like it and I just didn't give it a chance because we are in a process of clean testing. This driver has a sticky frequent USB numerator issue.

Do you want me to try with Zadig "brute force" method?

Anyway, debugging KA2 with CW 11.1 would first require a good programming, but I don't know if this USB installation driver problem could be the cause of bad RS08 programming. This could explain many things. But I can perfectly program and debug S08.

pgo · ‎03-30-2023

Hi Bob,

I haven't used the HCS08/RS08 features of USBDM for quite a few years so it is being neglected unless issues are raised. I also no longer have any facility to develop the Codewarrior 11 plugins so any problems with them are probably permanent (Codewarrior is a 32-bit version of Eclipse and development is very difficult on current OSs.) This is further complicated by my moving to Linux so any changes are done on Linux and then migrated to Windows in a Virtual machine using MINGW.

Because of the above, the actual Codewarrior plugins have been frozen for quite a few years. The installer simply installs the last version built several years ago - I can't touch these. The remaining stand-alone programming files are the only ones that get updated.

This shouldn't be a problem as the interface to the USBDM executables is not tight and the fact that they are now 64-bit doesn't affect this. There is a 32-bit executable incorporated in the plugin but it is very simple. The other versions of Codewarrior also need certain files built as 32-bit.

Anyway I am telling you this to indicate that it is difficult to debug or change things so don't expect a rapid fix.

Also I can't find the hardware that matches the one you are using!

Anyway, I have tried Codewarrior 11.1 with a very simple RS08KA2 program and hardware similar to your (USBDM_CF). This seems to work OK.

I did find a problem in the stand-alone RS08 programmer where it fails to verify with certain combinations of security options and security fields in the image but this is probably not relevant to your issues. The programming is successful - the verify fails with an internal error.

I don't believe the programming + verifying operation on the stand-alone programmer can be incorrect i.e. it will not falsely report success when it is in fact incorrect or incomplete.

Some particular comments:

The only situation I know where you will get a different result in Codewarrior and the stand-alone programmer is if you select different options for the security. When programming the BDMs "Image" must be selected as the security option otherwise the security area in flash may be modified and this will upset the flash checksum.
If you want to check the programming operation for yourself you can use the Memory dump program to read back the Flash and then load this is the programmer and use verify. This is in effect a round-trip verification. The only times this will fail is as detailed above.

So I am currently building a new version of USBDM to fix the minor problem mentioned above and I will do some further checks with Codewarrior when this is complete. This is currently stuck on a build error that occurs in Windows (MINGW) but doesn't in Linux - you figure.

After this is completed I will ask you to try this version in case there are some inconsistencies with the software/flash versions compared to the ones I am testing.

bye

BooleanBob · ‎03-30-2023

Dear PGO, thank you so much for your replies.

I want you to know that I very much appreciate your efforts and that thanks to your USBDM contribution I could develop and program lots of chips with no problems. I understand what you are explaining with reference to the lack of enough information to adapt new software to CodeWarrior. It is very discouraging from this side and I always had this senstaion that there were no more improvements from CodeWarrior side, even for old chip families, that I can assure that they are still in use. In my case these are part of products that I can still sell because I have little stock of boards, but after these news I will have to dispose hundreds of stock parts and switch to other equivalent parts (if any).

In this same minute I have downloaded a USBDM_4_12_1_305.msi. Thank you again for this. Tomorrow I will dedicate enough time for testing, re flashing one USBDM tool firmware and also install the 305 version in my PC so everything matches. This needs time because uninstalling the 295 version is a complete issue, as uninstalling always gets stucked in this version and I need to go through Windows registry to erase all entries.

Then I will pick up as much information as you requested and for you to analyze.

I'll be in touch soon, please keep tuned and thank you again for your kind dedication.

Greetings from Buenos Aires, Argentina !