#Ditch ms visual studio for gcc software
#Ditch ms visual studio for gcc code
#Ditch ms visual studio for gcc windows

Unfortunately we have the MCF54418 in a product which has hit the market a year ago and we plan to sell it for the coming years. Especially gdb has documented interfaces suited and known to mere mortals. I like the way you are thinking! :smileygrin: I believe the situation is nicer with the ARM chips as most manufacterers provide an IDE built around GCC/gdb. The other possibility is to choose the manufacture, processor chip and operating system based on the debug support provided by that chip maker or OS provider. In other words: there is hope :smileywink: gdb does not complain and knows about the symbols and the source code. I have not had the time to write a lot of code, but I have done a preliminary experiment: I load an. If we're lucky, we might be able to use CodeWarrior to write and compile our programs and then use GDB to debug. I believe that the debugging situation would be clearly better under Linux as we'd be able to run a stock gdbserver over a custom communications line or the AppTRK server provided by Freescale.

I did not find any information about a monitor being built into MQX.

#Ditch ms visual studio for gcc code

MQX seems to have some configuration options around cache invalidation to help when a debug monitor/BDM modifies data, or even worse, code behind the OS' back. The words 'BDM' and 'monitor' are to be found in the MQX source code. Maybe some of them might support your requirements? How much life is left in the model of MCF chip you're using? Many of them are approaching or have passed EOL, and there are a lot at 'not recommended for new designs'. Are you using MQX? Does it have any debugging support that might help you?

If it is an MCF54 then running Linux native on it, and debugging 'user programs' on it over Telnet or SSH might be possible. You didn't say which model Coldfire chip or what OS you're running.

#Ditch ms visual studio for gcc windows

Compile under Linux with command-line/Makefile GCC, edit with VI or with MS Visual Studio on a Windows VM. And that's with command-line GDB when it does work. The USB debug pod doesn't like our watchdog setup so we can't even get reliable single-stepping. We're running a 'bare metal polling loop OS' and debugging with print statements or blinking LEDs. However: a.) We're stepping outside Codewarrior: Less integrated, more development environments and b.) Without actually having it implemented, we're not sure how well GDB deals with the proprietary Codewarrior Compiler's ELF files.ĭo you have more information on any of the routes, experiences with these approaches or other, workable ideas?Įclipse/GCC/GDB might be possible, but you'd have to ditch CodeWarrior. This route is improbable, but maybe less so.Ĥ. App TRK is still supported by Codewarrior, but nominally only for applications running on Linux. The MetroTRK (of Metrowerks fame) protocol is no longer supported. We have not been able to obtain information on the GDI (Generic Debug Instrument, of Metrowerks fame) interface, so this route seems improbable.ģ. We have not been able to obtain information on the CCS protocol, so this route seems improbable.Ģ. To elaborate this a bit, we are currently thiking about a number of ways to achieve debugging access without BDM:ġ. What interface would I use to accomplish this? I know that this was possible with older (Metrowerks) CodeWarrior versions. Now I am looking for a way to integrate the ROM Monitor into CodeWarrior as a new connection type. On the Coldfire, we are running a ROM Monitor and we can speak with the ROM Monitor over a network interface. However, I would still like to be able to use the CodeWarrior debugger functionality. USB TAP for debugging, as I often have no physical access to the system with the ColdFire processor. During development, I cannot rely on e.g.

#Ditch ms visual studio for gcc software

I am developing software for Coldfire Processors with CodeWarrior 10.3 and 10.5. (Disclaimer: I have already asked this in the CodeWarrior section, but have been asked to carry my question over to this space.