I have tried a simple Blinking LED program on my STM32F4 Discovery board by following this tutorial.
However, I am not sure how to stop this from running, i.e., when I unplug the device from the PC and plug it in, I would expect it to reset itself (I might be wrong too, please correct me if this is not the case).
The board keeps blinking the LED on connecting it again. How do I reset it to its original state? Pointers to references for embedded programming would also be helpful.
If "original state" means the program that was shipped with the board, then you can probably download that at ST's website. You'll need to program the chip's flash with that stock binary.
Note that by programming the board you're programming the flash memory which will retain its contents through power cycles.
Related
I am trying to learn Linux by following instructions in "Mastering Embedded Linux Programming" by Chris Simmonds. By following the book and with some help from Stack_Overflow_1, i was able to build the MLO and u-boot.img.
However, when i connect USB cable to my PC and execute the ls /dev/tty* command, i cannot find any device with /dev/ttyUSB. All i can see are devices with /dev/tty0-63, /dev/ttyS0-31 and one /dev/ttyprintk.
Also, when i press down the S2 button and connect the USB cable, i can only see the power led glowing and nothing else.
I have properly built the u-boot (three attempts to get it right).
Also, as per the instructions in the book, i am only testing the u-boot stuff and yet to reach the kernal part.
If i remove the sd card and connect the USB, im an able to talk to my BBB over ssh (192.168.7.2).
How to i get the u-boot to work? Thank you!
If you don't have one yet, I'd recommend to get a USB-to-serial device (3.3V Vref). You connect it to the debug UART (J1) which is located next to the P9 side. Nowadays those are very cheap and can cost below 1$. Ones that feature a genuine FTDI part will be 5-10$ at least.
The serial port you are referencing is only available once the device has passed through U-Boot, booted the kernel and finally userspace has set up the communications.
Especially when working with U-Boot and the Kernel, low level UART access is crucial.
As a further note, could it be that the Book refers to the (white) original Beaglebone? That has a FTDI USB-to-UART chip on board and will allow you even U-Boot access. You can do the same things if you have the above mentioned USB device.
https://groups.google.com/g/beagleboard/c/eNDjK05spY8/m/GPvhcP52BAAJ shows that one needs to hold the space key to enter u-boot.
Also, the info. here might be more up to date compared to the book.
https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black
There is no way to copy and paste everything from the eewiki. I just left you the link. Enjoy!
I bought a DE1 SoC this summer and programmed a small CPU into the FPGA part. Back then, I had access to a PS2 keyboard that connected directly to the board, but now I don't and I need a way of communicating with the CPU. Luckily, the Cyclone V chip contains an ARM Cortex A9 that I can connect to the FPGA fabric and can run Linux distributions. The CPU in the FPGA part has a memory register which updates every clock cycle with the key scan code it used to read from the PS2 keyboard. My plan was to emulate this functionality by writing some code in C that would likewise read my keystrokes and send them over to the FPGA. This last part, I know how to do. It is the reading the keys part that confuses me. Ideally, I would like a function that, on execution, it read whatever input was coming from the keyboard, even if no keys are being pressed, without delay. I read some other questions on here that suggested things like getch() and getchar() and some other functions, but they all seem to require third party libraries and I am not sure these are supported by the compiler for the ARM processor.
It need not be necessarily C, it could be any other programming language that I could compile to run on the Cortex A9, it can even be assembly if it makes it more straightforward. All I need is to read whatever input is currently being sent by the keyboard, even if there is none. I can use a VNC to talk to the ARM chip over the local network or I can also connect to it via UART, whichever simplifies the process.
I am trying to program a Cortex M4 that was placed on a custom board. The processor is the MK64FN1M0VLL12. I wrote the code using the FRDM-K64F dev board, which uses OpenSDA to load the bin via USB. The code was written in mbed, which as far as I know doesn’t have any support for loading the program to the processor. For the production board, I was planning on loading the program via a J-Link programmer, since I didn’t include the OpenSDA interface.
Using the J-Link Commander tool, I’ve found that I have to hold the reset button down on the board in order to get any sort of response. When I don’t hold down reset, I get the follow:
When I do hold down reset, I get:
When I try to load the bin, I get messages about the CPU not halting. I get this whether I’m still holding down reset or not:
The O.K. message is a little misleading. I tried uploading a program with just a blinking LED, but the LED isn’t blinking.
I’m not sure where to go from here. Several days of Googling hasn’t led me anywhere fruitful.
I'm working on a custom Cortex-M3-based device and I need to implement in-application programming (IAP) mechanism so that it will be possible to update the device firmware without JTAG (we'll use TFTP or HTTP instead). While the IAP-related code examples available from ST Microelectronics are clear enough to me, I don't really understand how the re-flashing works.
As far as I understand, the instructions are fetched by the CPU from the Flash through the ICode bus (and the prefetch block, of course). So, here's my pretty silly question: why doesn't the running program get corrupted while it re-flashes itself (i.e. changes the Flash memory from which it is being run)?
A common solution is to have a small reserved area in the flash, where the actual flashing program is stored. When new firmware has been downloaded just make a jump to the code in this area.
Of course, this small area is not overwritten when flashing firmware, it can only be done by other means (like JTAG). So make sure this flashing-program works good to start with. :)
I'm not familiar with STM implementation, but in NXP chips the IAP routines are stored in a separate, reserved ROM area which can't be erased by user code.
If you're implementing the flash writing code yourself by using HW registers directly, you need to either make sure that it doesn't touch the sectors it's running from, or runs from the RAM.
Now a days many micro-controllers supporting IAP, that it is possible to program its flash memory while program execution in the same flash.
For IAP, program memory in the flash may be divided into 2 parts, one executable & other backup parts.
Generally we program the flash memory at a location (say, part-1) through JTAG, whose firmware version is 0.01. For IAP, i.e, program the flash in another part (part-2) while code is executing, corresponding API's should be provide in firmware version 0.01, which helps to program the flash part-2, After completion of programming successfully firmware version will be updated as 0.02. Upon processor restarts, program execution jumps to latest firmware by checking firmware version at initialization.
The part where the firmware is executing is called executable part, and other is back-up. why it is called back-up mean, suppose if there exists any firmware corruption while programming, firmware version will not update & upon restart, program control will automatically jumps back to back-up firmware after checking version number.
Another good way to do it is using custom made bootloader. However STM IAP is not stored in Flash so it can not be overwritten by it self. What generally people do is to spilt the flash in two parts , one is reserved for Custom made Bootloader and Another is for application. Bootloader makes sure that it does not write to its own assigned area. Bootloader can be programmed through JTAG and later application can utilize bootloader to program itself.
As far as I understand, the instructions are fetched by the CPU from the Flash through the ICode bus (and the prefetch block, of course). So, here's my pretty silly question: why doesn't the running program get corrupted while it re-flashes itself (i.e. changes the Flash memory from which it is being run)?
This is because, in general case writing/programming to flash memory is not allowed while you are reading from it(i.e executing code).
Have a look at this for some ideas on implementing IAP.
s3c44b0x does not support flash breakpoint(unlike other processors such as lpc1758 which has on-chip flash), then how to debug bootloader when it still runs in the flash?
Logic analyzer, printf, ICE, and EPROM / Flash memory emulator would be the old-school ways.
The Samsung S3C44b0x (ARM7TDMI) claims to have an on-chip ICE breaker debug support, so getting a In-Circuit Emulator might be what you want to do.
Added:
If you have enough RAM, during the booting from Flash you could print log messages to an in-memory buffer in RAM, and then output this buffer, using printf to serial later once the UART is initialized.
2nd addition:
To isolate which portion of the bootstrap process, you could replace modules or steps with empty stubs, with the sole intent to isolate crashing. The approach is to narrow the possibilities of failure. Make an firmware image that initializes only the first basic step e.g. the system's memory, if that works add your task or process housekeeper module / step, later including initializing the UART, etc.
If you have the output pins, add some LEDs to count the sections in binary, allowing your to see which section of code is currently running.
Check out the book Debugging Rules and print off your own copy of the free Rules of Debugging poster. It's a short book, and while nothing revolutionary it solidifies the debugging process, and helps most people be more organized and methodical in their debugging.
References:
The ten secrets of embedded debugging
SO: What simple method can I use to debug an embedded processor without serial port or video?
Softpanorama Debugging Links