Debug RM48L952 chip with GDB

Hello Vitally,

I have copied a co-worker on this thread who has discussed the GDB server debug previously. Perhaps he can be of some assistance to you on your question. He should get back with you soon.

Vitally,

Hi,

Do you *want* to use CCS with the J-LINK , but the CCS Driver for J-LINK is not working and therefore you are trying GDB Server as a fallback.

OR do you really want to use GDB as a preferred solution?

We could try to help with either path you want to go down... although please be patient because we are not as familiar with the J-LINK as the XDS100v2.  

You mention that GDB is working from the command line.  But which IDE are you trying to use when you say GDB is not working (disconnecting after hitting a breakpoint?)

Regarding your compiler question.  I don't think the compiler should matter, as long as the compiler output is EABI format.   But I haven't tried using GDB to debug EABI binaries from CCS.  I have done it the other way (used CCS to debug GCC generated EABI) and this worked well.

Anthony,

Primary use of CCS will be designing products with Hercules family.

Planned secondary use of CCS -- transfer existing software to CCS IDE, for ARM7TDMI core.

The only way to debug ARM7TDMI in CCS is to use GDB.

Also I have very specific problems with RM48, CCS and JLink. When I discover MotorWave software for DRV8301-RM48-KIT, there are instructions to setup IDE for comfort work, such as: show and continuos update used variables while FOC firmware is running and motor is spinning. With use of beta version of JLink driver, it is unable to see or edit variables while firmware is running, there is need to stop firmware (halt CPU) to show or edit variables. And when PWM for motor is to high (it is very usual situation), motor windings begin to heating. I want to use original GDB server from Segger to try to avoid such situation.

It seems that JLink does not have possibility to read or write memory without halting CPU.

According to wiki, TI has beta support of JLink http://processors.wiki.ti.com/index.php/J-Link_Emulator_Support

There are my other topics in e2e and Segger.

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/177500.aspx

http://forum.segger.com/index.php?page=Thread&threadID=1578

So, 1) JLink is unable to use for correct work with MotorWave, and no any word is written in TI wiki or forum; 2) changing to GDB I want to do two tasks: debugging ARM7TDMI core and try to use originally GDB server from Segger.

I understand that used in Code Composer GCC and TI ARM compiler are designed for Cortex cores, not for older one. Also I understand that used in CCS newlib (for GCC workflow) designed for Cortex-M and Cortex-R cores. So I have to change my workflow to GCC and build own GCC toolchain and other runtime libraries, for use with ARM7TDMI.

Also I have XDS100v2 in RM48CTRLCARD and may change to gdb_agent_console to setup work.

I use archlinux 64bit and CCS5.4

Regards, Vitaliy

Hi Vitaliy,

Thanks.  That's quite a lot to digest though - I think you're out on the bleeding edge in terms of combinations of things so we probably need to focus on reducing some of the variables and solving one thing at a time.

Generally - http://processors.wiki.ti.com/index.php/Linux_Host_Support mentions that many linux distributions will work but only Ubuntu and Redhat are tested.   So I don't know about Arch.  I checked http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions and it doesn't say that ARCH is based on redhat or debian (like ubuntu) so that probably goes into the unknown variable column.

Also, on the  CCS Jlink page http://processors.wiki.ti.com/index.php/J-Link_Emulator_Support I only see that the Cortex A,M,R devices are listed not the ARM7TDMI.  

Now, you can debug TMS470 ARM7TDMI devices with CCS but you have to pick one of the supported emulators.  For example the XDS100v2 does not support ARM7TDMI because when 100v2 was developed, ARM7TDM was already quite old.  But  if you select the XDS200 USB emulator - the TMS470R1A256 which is an ARM7TDMI part is listed.   That is probably the lowest cost emulator that supports ARM7 under CCS.

So I don't think needing to debug TMS470 would necessarily mean having to use GDB or JLINK.

Then did you *want* to build your own GCC toolchain?  That is quite a commitment and I would imagine this would be something you might find better supported commercially.   You might check out Atollic if your preferred combination is the JLINK and mutliple generations of ARM (from ARM7 to Cortex R), with a GNU based toolchain.   We will be adding them shortly on the Hercules page under IDE vendors.   Another option might be CodeSourcery from Mentor but I'm not sure if we're supported by them.

Last, I skimmed the Segger forum post you linked.  In this particular case the processor is not cached and therefore caching is not a problem for non-intrusive writes.   We have a 'DAP' port that is a sort of like a JTAG scannable 'dma' engine that enables memory accesses through the debugger without stopping the CPU.  I think Segger probably would know what this is so I'll try to clarify on that post and see what they might have support for already.

Aside from that - since you've got so many different 'fronts' where you're trying new combinations, I think we need to pick one area to focus on.   Probably it would make sense for you to look at some of the other IDE vendors like Atollic and see if they are a good fit for your needs;  and then decide. 

If you stick with CCS,  then I think the GDB server path for ARM7 and Cortex R isn't supported and you'll really be on the bleeding edge.  If that's what you want we can do what we can in a reasonable amount of time to help but I think it might be better to get an emulator that supports both cores and confirm the Archlinux / CCS combination question if you're going to continue down the CCS path.

If you take ARM7 out of the picture completely then there might be more options with the CCS / Segger combination when you just focus on RM48 Hercules.  But throwing the ARM7 into that mix puts you in unsupported territory.

Ok, so to summarize:

   - As a next step I will try to clarify w. Segger the DAP being key to background updates of memory on your motor kit.  

  - For a next step if you would please look over the options and then decide on a path to go;  and also a next objective that you want to work  [one thing/combination, like for example Hercules with JLINK on CCS] so we can focus on getting that step knocked out - that would be great.

Thank you, Anthony.

CCS is not first IDE which I try to use for RM48L952 chip.

At beginning I used Keil MDK-ARM Pro (used in many other projects in our development department). But there was a problem in debugger leading to unable to debug any Cortex-R4 core, Keil supporting team tell me:

bad news. Our development team won't fix this issue which affect all Cortex-R4 targets. Since the market demand is very low for this CPU cores and the fix will require lots of effort our marketing and engineering team decided to reject this fix.

DS-5 in combination with DSTREAM (http:/www.arm.com/products/tools/software-tools/ds-5/arm-dstream-high-performance-debug-trace.php) sounds like a suitable tool combination to support your Cortex-R4 device.

The next version of DS-5 (scheduled for next month) should support this device/board out of the box.

Keil ticket for found bug is here. I am not sure that you can read it.

Therefore it is better to remove Keil MDK-ARM from list of supported IDE at TI web site for Cortex-R4 targets. Keil recommend to use DS-5 instead of MDK-ARM.

I will attach test project for Keil MDK-ARM. Keil can compile but cannot run debugger. It is a very simple project configured to run from RAM.

3568.RM48_Keil.zip

Now I have to buy CCS+XDS200 and very carefully think about others IDEs different from CCS and prefer to use IDE from chip manufacturer.

There was no any problem with Archlinux and CCS, I follow instructions in wiki and CCS is working.

JLink drivers for linux from Segger perfectly support many cores, and ARM7 too. My question was about "how to switch on Segger driver for JLink (using GDB server, which is a part of segger linux driver) instead of beta version of CCS JLink's driver".

Maybe better way is still to use Keil MDK-ARM for ARM7 and CCS for Cortex-R4, JLink for Keil and XDS200 for CCS. Then no any actions need to do, all will work "out of box", without GCC toolchain (no GDB too). If problem with JLink driver in CCS will be fixed then I don't need to buy XDS200. But JLink support for CCS is not working at e2e for unknown reasons (do you know "why?").

I tried out to use JLink in CCS because I have JLink ULTRA+ and read about JLink support for CCS. And it is a way of troubles.

Please write some information in your wiki for JLink in CCS (unable to use for discover MotorWave because of halting CPU for memory read/write) or fix bug in JLink CCS driver. And please remove Keil MDK-ARM from supported IDE for Cortex-R4 chips. I lost a lot of time because of incorrect information at TI website (try to use Keil MDK-ARM, try to use JLink, and it is my luck when I powered DRV8301-RM48-KIT from laboratory power supply). If no information about JLink or Keil MDK-ARM has been wroten at TI website then I should use CCS and XDS200 at beginning of my work with Hercules family.

No any actions need from you, I still to use Keil for ARM7 and CCS for Cortex-R4.

Regards, Vitaliy.

Hi Vitaliy,

We apologize for the trouble you've had especially if our website information is out of date.
Frankly the Keil information is a bit shocking because we've tested the Keil MDK with HalCoGen and even had Keil manufacture the first Cortex R4 EVMs for us (on the TMS570LS20216 family of products).  

Our marketing team is reaching out to Keil today to find out what this issue is (we can't actually see the ticket from inside TI unfortunately) and if the situation is really that they are not going to support Cortex R4 we will remove Keil from the supported tools list.   Thank you for bringing this issue to our attention so we can run the issue down.

I'm quite confident that the Segger JLINK + CCS path will be something that will work.  Segger has been very responsive and helpful already and the next actions are in TI's court.  So I think this path will be viable and if you can wait and make use of the XDS100v2 you might be able to save yourself the cost of the XDS200.  Of course the XDS200 is much faster;  so it might be a good investment.   I had mainly recommended it as a solution for both ARM7 and Cortex R4 under CCS.   But if you are going to stick with your existing solution for ARM7 then I think it just comes down to a performance question -- whether you can live with the XDS100v2 speed or not.