I'm working with an 8051 (Cypress FX2LP) that doesn't have jtag/bdm capability. Typically, developers on this project have been using ad-hoc serial printfs for debugging. I'm looking into options for serial debug monitors such as Keil's Mon51, Isd51 or IAR's generic ROM-monitor.
I'll need to modify/configure this debug monitor to write to code RAM (to set software breakpoints). I'd guess that most 8051 debug monitors offer the ability for such modifications in order to support Harvard architecture or bank switching.
Does anybody have recommendations for serial debuggers for 8051 or similar processors?
Have you had to modify it to write to Harvard code RAM or flash etc?
I used for years Keil uVision PK51 and the Cypress FX2 EZ-USB Development kit. This kit (EZ-USB_devtools_version_261700.zip) worked correctly with FX2 and FX2LP.
It includes a Windows driver that automatically downloads the monitor firmware on board and stay resident in 8051 memory. This monitor takes control of one of the 2 serial board and manage the communication with the debugging tool. You have to set the Keil environment debugger to use the "Keil Monitor-51 driver".
Once your fw is downloaded and running you can set breakpoints, display watch, etc...
The Cypress driver works correctly with Windows 2K/XP. I never tried it with Vista or later. Probably there is a newer version of the Cypress that is able to run on the latest Windows.
Good luck
I have been using Mon51 with the Cypress FX2 for going on 10 years with very good success. In addition we use the RTXtiny task switcher and code banking. I have found the monitor to be generally solid and with enough functionality for our needs.
The Mon-51 code comes as a library from Keil, so it is not available. A couple of years ago I was having trouble getting code banking to work with the monitor, and since I wasn't getting very good support from Keil, I started to disassemble the monitor to figure out what was going wrong. Before I got very far I solved my problem and I never finished the reverse engineering project.
Our hardware platform is "von-neumanized" so that code and xdata space overlap. This is necessary for the monitor to work correctly. We have modified the monitor initialization code so that it runs at 115200 baud from an external uart and that works well. In addition we had to build our own version of the monitor so that it was located at a different location in memory. Keil has actually made it pretty easy to configure things without having to dive into the actual monitor code.
Related
Is it possible to work at Raspberry Pi Pico using Windows 10? My question specified is: do I have to install any Linux distro, for example Raspbian, to be able to work at it? Do I also need to use SD card to work with it?
Just want to receive feedback, cause I'm confused and also kinda new to embedded systems
I may share my experience so far, I'm not an expert and this list does not claim to be complete at all.
The pi pico can be programmed by using
Picomite Basic (found here: https://geoffg.net/picomite.html) which doesnt need anything installed on the PC except a terminal program (I am using Tera Term)
MicroPython (never used it myself, afaik Thonny - found here: https://thonny.org/ is the preferred IDE )
C/C++/ASM This is what I am using, the SDK is available for Windows, Linux and Raspbian (MacOS maybe too?), an excellent guide on how to install it and how to use it is found here: https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
Arduino The Pico can even be used as an arduino device too, a good point to start is here: https://github.com/earlephilhower/arduino-pico
Keep in mind, that the interpreted languages (basic and python) are easier to handle (no big SDK or framework need to be installed on the PC, copying code to the pico is a relative easy step) but at a cost of speed. If you need a lot of cpu power, compiled languages are by far the better choice
To answer your questions, yes, no, and no. You should be able to get going on Windows 10 with just the raspberry pi pico and a micro USB to USB cable.
I got started with mine this weekend - seeing the on-board LED blink finally made me so happy.
The official getting started guide pointed me at this script for getting started on Windows.
It set up docs, examples, visual studio code, and more for me. Between its README and chapter 9 of the getting started guide ("Building on MS Windows"), I was able to get my little light blinking :)
Good luck to you on your embedded journey!
As an alternative, an in addition to #Tommylee2k's helpful insights, you can develop and run Python software for a Pico with absolutely no software needing to be installed on a Windows PC.
At its most basic level, you press the BOOTSEL switch and insert the Pico's USB cable into your PC, and the few MB of space on the Pico appear in your Windows File Explorer as a USB disk drive.
You then write your microPython software using any text editor you prefer. All these general purpose modules are available. And all these Pico-specific modules are available.
You then copy (drag and drop) your Python script to the Pico disk drive and save it as main.py.
The Pico will then run that script on every subsequent power-up. Of course you can re-attach the Pico to your PC and edit the file at a later date.
That is adequate and simple enough. If you want a REPL and friendly editor and console logging and other developer-friendly features, you can install Thonny for free and code more effectively but it is not actually absolutely necessary. It's a bit like driving a car without ABS, without an automatic gearbox and without aircon - it can get you from A to B without problems but there are easier and more comfortable methods.
recently I have bougth a ESP32 devkit and a low budget FT4232H jtag adapter which I managed to setup in VSCode using the Espressif-idf plugin.
Basically it seems to work so far. I can build, flash and monitor the ESP32 from VSCode. Also also managed to setup the debug configuration, but I am still missing some features in while debugging.
I can step through the code, watch variables and see the call stack.
But I can't see periphals, registers or memory
I guess I have to set some more options in GDB, OpenOCd or even ESP32 config but I don't know which ones.
Any ideas were i have to dig?
You appear to be almost there.
I have a very similar interface with the memory loading afterwards but only after stepping into certain operations.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/debugging-examples.html
Following this document produced by espressif. Memory can be accessed and stepped into using the keyboard shortcut (x) when using openOCD.
Give that a try.
I am currently programming an embedded system, which works with a GPS modem. I do not have any problem debugging the software as long as I do not activate the GPS module.
As soon as I do it, I cannot use any break point anymore nor stop the program. If I try to do it, the software to debug (Atollic TrueStudio) writes "Starting target CPU" and nothing changes.
Note that I overtook the programming of this system, which works. I need to develop it further. I can compile it without any problem, but not debug it (even if use the same develepment tool, the same software and the same hardware).
So the problem is neither the hardware nor the software. But probably in my way of debugging (I do not think, they developed the software without seeing anything).
Does anyone have an idea, why does the activation of the GPS make stopping the debug? Do I have any other drivers, than the ones proposed by Atollic, to download?
Parameters of the embedded system:
Microprocessor: STM32F405RGT
Operating system: FreeRTOS
GPS Module: RXM-GPS-RM (Linx company)
Develeppoment tool: Atollic TrueStudio 5,6,7,8, 8pro (I tested all of them. Atollic 5.1.1 has been used to develop this software)
I have never worked with Siemens' SIMATIC industrial automation system, but I need to do following:
We have an industrial computer with Windows CE (for example an x86 Siemens TP700 comfort).
Is there a way to create a .NET application that would be able to work with SIMATIC ET200?
Or do I always need "SIMATIC NET" or Step7? I was told that SIMATIC NET does not work on Windows CE. Or can I use some OPC server that does not require SIMATIC NET?
Or is it impossible to use SIMATIC modules under Windows CE? It could be conclusion as well.
Try to lauch \Windows\cgacutil.exe on your CE platform. If it is there, it will tell you the version of the '.Net compact' framework. If there is one installed, you can write applications targeting that particular version. The '.Net compact' is only a subset of the full .Net on desktops.
Hmm, first of all which ET200 fieldbus device want to work with?
Generally you must have ET200 with ethernet (ProFiNet - process field network) interface, than at least you don't have an IM151-7 (or 151-8) that are a CPU as first unit in ET200 rack you need other software to make you pc as a master profinet device, the slave device are basically stupid devices as long as initialized by a master device, that usually is the CPU.
Second thing: the TP700 is a WinCE Panel,with basic function that need to programmed into HMI software designer (WinCC for TIA Portal) and has a very limited resources.
My point of view: first you need to explain what need to do: a S7-1200 CPU even the most basic model do everything you want: address the ET200 rack, read and write the I/O data and collect them ready to be read or write from TP700: you need half day for all job, most time is need to do the graphic interface.
The other solution could be put a linux CPU (raspberry or everything else) that the necessary tasks to address ET200, read and write data to it, process the data and place them readable from TP700 (programmed with WinCC)
I'm programming automation devices from 27 years (I'm 46 year old) and I've basic knowledge of pc programming: from my point of view you get best result, reusable code, less time, less heachache with a plc cpu instead of pc code.
I'm currently setting up vmware Server 2.0 for kernel debugging with gdb ( see this setup guide ) and someone asked me why not use kvm?
So I ask: kvm vs. vmware for kernel debugging / USB driver development
what are the pros and cons of each?
Driver development? are you working on a driver for a particular piece of hardware? if so, then you probably won't be able to use virtualization, because the virtualized instance won't have access to the new hardware.
For this you will need two machines, one running a remote debugger on the other.
*Edit: * Apparently you're developing a driver for a USB Device? this is one area in particular that a VM actually Can help. These days most VM's have the ability to delegate specific USB devices to a guest OS.
That said, this situation doesn't really offer any benefits over the remote debugger option, because you still need a way to inspect the state of the running or crashed OS, and VM's offer very little assistance in this regard. You might be able to replay saved states from just before a crash.
You might be able to get a bit of traction using UML, which would allow you to do local debugging as on a regular user process, which is a little bit less trouble.
Instead of answering the direct question I'll add another option... Depending on if the kernel in question is a Linux kernel, and what part(s) of it you are working on, you might find that UserModeLinux (included in the 2.6.x source, and available as patch sets for 2.4 and 2.2) may trump both of those options.
As it runs the kernel as a userland process under the host kernel it is easier to attach common debugging tools to. I believe it is very commonly used in the early stages of updates/additions to file-system related code. If you are developing/debugging modules that interact directly with hardware it may be much less use to you though.
Reference links: home,
other
I recently started building GNU Mach/HURD and found the combination of QEmu/KVM to work really quite well.. for the following reasons:
QEmu presents quite a clean environment
Networking has alot of options
I can easily mount the filesystem using a raw device file / loopback
Bottom line is, for kernel work I just want the minimum of functionality to boot and see the result. VMWare is much more for usable virtualization rather than down-and-dirty.
There is however no comparison to booting on a real machine with real hardware. The VM environment can seem like a safety blanket somtimes ... because even my toaster would know what a Realtek RTL8139C was.
If it is a "real hardware" device, of course, vmware will not emulate it, so you won't be able to debug the driver under it (nor will any other virtualisation software, unless you extend one to do so).
Device driver debugging can be done to some extent with a real hardware machine with a normal kernel - although there are obviously things you can't do - like set breakpoints.
It is still possible to attach a debugger to the kernel and inspect stuff. Moreover, traditional printf() debugging is quite possible (printk, anyone), and there are various features in the kernel which make debugging easier. It's possible to build the kernel with various debug options to try to detect pointer problems, memory leaks etc.
By default, the kernel even gives a nice-ish stack trace on the log when it encounters an OOPS or BUG condition (obviously this does not necessarily get written anywhere if the system hangs or crashes). Of course a pointer-out-of-range condition happening inside an interrupt is a recipe for disaster, but you could still get a stack trace on the screen immediately before the panic :)