USBDM - Version 4.10.4 (RS08/HCS08/HCS12/CFV1/Kinetis BDM)

[pgo]

Dear All,

USBDM has been updated to V4.10.4

Please post any queries on this version in a separate thread - I really can't cope with this newfangled setup!

Documentation available at: SourceForge

Applications available at: SourceForge

Source code is available at: GitHub eventually.

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.

USBDM V4.10

=========================

V4.10.4 (January 2013) -

   - Added support for Codewarrior 10.3 Release (This version does not work with the BETA)

   - Added customisable security options to programmers

   - Improved HCS08/HCS12 programming speeds (15~30%)

   - Added Codesourcery and USBDM API examples to installation

   - Updated/added Codesourcery instructions to help files

   - Numerous bug fixes to GDB Server

   - Improvements to handling secured devices

   - Added Examples to installation

   - Added OpenSDA firmware (This allows use of FRDM-KL25 board as general purpose Kinetis BDM)

V4.10.3 (November 2012) -

   - Updated device driver installation (V1.0.1) (removed unnecessary driver).

   - ELF Files now supported for MC56F80xx devices.

   - Changed to shared DLLs build for wxWidgets.

   - Bug fixes:

     - DSC Access to ONCE registers when target running

     - Fixed BDM doing reset when setting target even if already powered.

       This was interfering with doing a 'gentle' connection to a running target.

     - ARM interface now reports access errors on failing memory access rather than following access.

     - Corrected corruption in large reads for ARM GDI Interface.

[lucianon]

Hello PGO, you made a great job (USBDM)!

I´d like to modify this USBDM to work without a PC. I´d like to share the JM60 flash (44kb available/not used) to storage a S19 file and program  without PC. To do it I need to understand what data you are send to programmer board. I saw the address and data for every BDM write comes from  the PC program "programmer.cpp" than I need to compile it.

My question is:

     What compiler did you use to make a PC application? (sorry about my lack of experience in PC programming I need a tip)

     I tried to open this files with Eclipse C++ but there are missing a lot of headers.

     What files I should download to open this complete PC project?

see the eclipse I´m using:

thanks,

Luciano

[pgo]

Hi Luciano,

refer to this thread for some discussion of building:

Need a lot of help getting/making Java DLL

Also

USBDM: Building USBDM Software.

bye

[juanmanuelmerca]

Hello Pgo.
Could let me know if USBDM it works on Windows Seven 64-bit?
Thank you.

[BlackNight]

Yes, I have it up-and-running on Windows7 64bit too (Debug External Processors with USBDM and Freedom Board). A had a strange driver problem, but looks this got resolved with re-installing the drivers. I only have an outstanding problem with programming a larger file (on KL25Z). I'll send that project to pgo so he might have a look.

[BlackNight]

In case someone has the solution, here is my problem with USBDM and FRDM-KL25Z:

programming the attached file with USBDM and CodeWarrior for MCU10.3 gives:

I tried it then with the Flash programmer, and here I get the indication, that there is a range problem:

(it reports chip ID 0x25151486)

After that, USBDM stops working (a reboot helps).

I checked the arm_devices.xml, and things look ok to me, and it works for smaller programs too:

	<memory id="kinetis128K_Flash_B0" type="flash" registerAddress="0x40020000" sectorSize="1024" alignment="4" securityAddress="0x0400">
	<securityEntryRef ref="Kinetis-default-security" />
	<memoryRange start="0x00000000" size="128K" />
	</memory>

That binary works with P&E and the original USBDM. I have attached the S19 file which causes the problem.

So: it works with smaller binaries (few KByte), but things go really bad with this larger 60KByte binary.

Attached is the project with all sources. The S19 file to reproduce the problem is inside the FLASH subfolder.

Any idea/fix?

Many thanks,

Erich

[pgo]

Hi Erich,

If you look in the .s19 file in the Flash directory you can see that the file contains data located [1FFFF000-1FFFFFFF] at the end of the file.  It's also in the .elf file.

I'm not sure where this is coming from but its likely that you have something incorrectly being programmed that is actually meant to be RAM[0x1FFFF000..0x20002FFF].

The programmer (quite rightly :smileyhappy:) objects to programming this.  I'm puzzled by it hanging though.  This did not happen when I tried it.

Deleting  the offending range enables the file to program OK.

If your other programmer works OK it may be because it ignore writes to RAM.

bye.

PS. tested with V4.10.5 (unreleased)

[BlackNight]

Hi pgo,

thanks for your fast response!

Hmmm. That application is created with gcc.

It looks it comes from this

.mtb	0x1ffff000	0x1000
	0x1ffff000	. = ALIGN (0x8)
	0x1ffff000	_mtb_start = .

Which is a 4 KByte Micro-Trace-Buffer in RAM (see

Debugging ARM Cortex-M0+ Hard Fault with MTB Trace | MCU on Eclipse) which is defined in sa_mtb.c as

unsigned char __attribute__((section (".mtb_buf"))) mtb_buf[__SA_MTB_SIZE] __attribute__ ((aligned (SA_MTB_ALIGNEMENT)));

It is not referenced by the application source, but by the trace module on the chip, so it is marked in the linker file with KEEP:

  /* reserve MTB memory at the beginning of m_data */

  .mtb : /* MTB buffer address as defined by the hardware */

  {

    . = ALIGN(8);

    _mtb_start = .;

    KEEP(*(.mtb_buf)) /* need to KEEP Micro Trace Buffer as not referenced by application */

    . = ALIGN(8);

    _mtb_end = .;

  } > m_data

I'm surprised to see this present in the S19 file. :-(

And yes, it seems that my other programmers are either ignoring it (or writing it to RAM?).

I removed that trace buffer from the application, and now it programs it :-)

Thanks to your help I was able to solve this, but I guess anyone who will use a trace buffer will run into this again? Maybe best if OSBDM could ignore these writes to RAM?

Many thanks again,

Erich

[pgo]

Hi Erich,

I spent some more time playing with the trace function  on the MKL05 chips,  It's a nice feature.  Thanks for the tutorial you have posted,

USBDM does support writes to the RAM when operating within the debugger.  It's intentionally  disabled in the stand-alone programmer.  I still think this is the correct choice.  I cannot think of any occasion when an image should have data that is intended for RAM.  In the normal course of events this would mean that there is something wrong with the memory linker file.  This would be especially dangerous since the action when operating under a debugger would be different from when it is operating stand-alone.  For example, RAM data would be initialized in the debugger but not in the final operating situation.  This can lead to some very subtle bugs that are hard to track down.

In the particular case of the trace buffer situation the trace function should be disabled before producing the production image.  This will remove the trace buffer from the image.  This could conveniently be done by having two build targets -Release and Debug.  The trace function would only be enabled in the Debug target.  This would also allow the optimization and debugging options to differ as well.  I note that the projects for the KL series only have the single target (FLASH).

I suspect the reason the trace buffer is done in this fashion (rather than as part of the BSS) is so that it is cleared by the debugger when loading the image without requiring any code to run on the target.  The alternative of having it loaded in the BSS would mean that the trace buffer was not cleared until the C startup is run.

bye

[BlackNight]

Hi pgo,

I agree with you: the stand-alone programmer should not allow writing to RAM. But a better error message or warning would be a good thing.

But my problem is not the programmer: my binary failed with the debugger too, and here I had no indication what was wrong. Then I tried it with the programmer, and then it failed (because of the RAM section). So I thought the root cause is the same for both the debugger and the programmer, but you say that it should behave differently.

The only solution I saw was that I had to disable the trace buffer with the KL25Z project I had, and then it worked in the debugger too. Strange. I think I need to re-verify things again.

I think the debugger does not clear the trace buffer, and the debugger is not affecting it. What the 'trace' portion of the debugger does is to check if there is such a buffer in the binary, and then assigns the trace hardware to point to it (with the size given). I believe it is more a problem of gcc that it puts it into RAM. Probably because of the 'keep' attribut in the linker file.

Debug vs. Release: well, that's an old (and endless) question in the industry :-). To me, the 'desktop' world thinks in 'release and debug', while the embedded world only thinks in 'debug', so that 'FLASH' target is really more suited for the embedded world. But it is really easy to add another build target and then make it different in Eclipse, so it can fit everyone's needs.

Erich

[pgo]

Hi Erich,

I tried out your example program with CW10.4 and USBDM 4.10.5.  It seemed to work OK with and without tracing.  Hopefully the problem has been fixed in the next version of USBDM. I don't know what the program does so it's an incomplete test.

bye

[BlackNight]

Hi pgo,

ok, then it is hopefully fixed.

The program runs a small line following robot based on the FRDM-KL25Z and a Pololu chassis (http://mcuoneclipse.com/2013/03/28/maze-solving-frdm-kl25z-robot-goes-backward/).

It failed to download with the debugger for me (with 4.10.4a).

BTW, I managed to get USBDM working with the new CodeWarrior for MCU10.4 (Adding USBDM to CodeWarrior for MCU10.4 | MCU on Eclipse).

I have not spend much time on the wizard XML patch, but obviously the patch XML file needs to be updated for the next USBDM release. Any chance that MCU10.4 will be supported in 4.10.5?

Otherwise I'll spend some time next week-end to work on a patch XML file.

Thanks!

Erich

[pgo]

Hi Erich,

I've just started playing with CW 10.4.  It appears that the new project wizard XML files have not changed much so the same patch works for 10.3 & 10.4. (As you discovered!).

USBDM 4.10.5 will support CW 10.4.  It should be released in the near future.  I'm spending rather a lot of time updating the support for Eclipse + Codesourcery as an Opensource alternative to Codewarrior.  Obviously not as capable.

bye

[BlackNight]

Hi pgo,

yes, that version 3 XML added USBDM do the connection list, but I had the issue that the project was not created (internal java null exception or something like this). Are you saying that the project gets created properly for you?

Maybe I have missed something?

Thanks,

Erich

[pgo]

Hi Erich,

You probably missed some files.  USBDM modifies several areas of Codewarrior but it's probably not worth pursuing.

I've just uploaded USBDM V4.10.5 to Sourceforge which will install with CW 10.4.

bye

[BlackNight]

Hi pgo,

thanks for that 4.10.5 version. With this one I'm able now to download my Zumo FRDM-KL25Z application :-).

The bad news is that I was trapped by a problem that USBDM was not able to connect to a KL25Z in low power mode. It failed to connect/talk to the device. I was able to recover it with the original P&E OpenSDA. I'll try to reproduce this and post it on in a new thread.

Many thanks,

Erich

[andreitatar]

It surely works!

[andreitatar]

Hi,

I am continuing from the other thread. I checked and I have the latest version (4.10.4).

As I said, I can not debug from CodeWarrior 10.3 but I can program the board with no problem when using "ARM programmer" software.

Initially the ID of my chip (MKL05Z32 in QFN32 package) was not recognized, so I added it in the XML file and now it works. Is there something similar I need to do for debugging to work?

The error is "lost connection with debugger" or similar. I will check when I get home.

I'm using FRDM-KL05Z Kinetis development board.

Thanks

[pgo]

Hi Andrei,

I have tried out a FRDMKL05 board with USBDM 4.10.4 and had no problems (apart from changing the ID #) with a basic test so I can't really suggest a solution.

Could you do any/all of the following and I will see if I can find a reason for the problem:

• Please post information about you system - OS and  machine type (AMD/Intel)
• If the project is not confidential - Export the project and I will try it out on my PC
• Turn on "Use debug Build" in the driver Debug options.  This will produce a log in the %APPDATA%/usbdm directory that may suggest a reason. (usbdm.log and another gdi log)

bye

[andreitatar]

Got it working! Thanks a million times.

The problem was that I added a new entry in the XML file (named MKL05Z32VFM - I think) with the new ID. After removing it and changing the ID for MKL05Z32, it all works fine now!

Thanks!

[BlackNight]

I was puzzled by that as well (not able to debug the FRDM-KL05Z with CodeWarrior for MCU10.3). Finally, this thread has lead me to the solution. I have described it in detail in

Debugging FRDM-KL05Z with USBDM | MCU on Eclipse

I'm able now to debug my FRDM-KL05Z and UsBDM :-)