I have an STM32F103 that I'm re-flashing remotely using a different MCU through its UART port (using the boot loader). It works perfectly fine, I have multiple devices that have been successfully flashed with the right code. But occasionally there comes along a device that has stopped working because the STM32 code flashed is not the right one. The whole bin file is flashed using the other MCU, but the STM gets "bricked" (not exactly bricked, it's just has a wrong code). When I re-flash the device using my PC everything is working again. Why would the hex wrote into to the STM fail?
Brief:
*Using UART bootloader to flash STM32F103
*Occasionally this method fails, and so the STM stops working.
*Is there a method to check if the data written into the code space is valid?
*The STM is not bricked, it's just a wrong code inside the flash. When I read back the flash from the code space, this is smaller than the file that should have been flashed.
*I'm using the STM in system boot mode. [AN2606]
You can read the data written in STM32's flash using the boot-loader command just the way you write the data (bin file) to flash. This way, you can check if the data written (or new code) written into flash is same as the original binary file. Re-flashing is successful only if these two match, else you can re-attempt to flash the STM32.
Related
Why would the file system (CIRCUITPY) of an Adafruit board running CircuitPython not show up when connecting it to a suitable host via a micro usb cable?
This happens to me often, usually when I am copying files via Windows, most often with my trinket which uses the integrated chip flash memory rather than the separate SPI flash chip. Why? I don't know. A bug somewhere obviously. :)
So the solution.
Always save your work files locally or use a source code solution like git
Switch to the boot mode (double click reset)
Drag the erase.uf2 file to clear the flash memory
Drag the circuit python uf2 file to reflash python
Restore your files saved on your PC
Basically, I've made it a habit to assume the flash memory is temporary and volatile and not store any critical code only there.
You can read more about the erase uf2 and reflashing, general troubleshooting here:
https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting
Besides your first answer about the cable, because of the relatively inexpensive nature of the boards and direct access to their power/ground sometimes the EPROMs that the file system are hosted on just go bad and give unexpected results. Best idea is to:
Test your environment with another board.
Reflash micro python on your board so you can start from scratch (didn't mention if you'd tried that).
JerryN mentioned the most common cause of this is using a USB cable with no data wires. Some USB cables are designed for power-only and have 2 rather than 4 conductors. These will power the device but will prevent mounting of the drive and use of the serial connection over USB.
Unfortunately these cables are often not marked as power-only so can be difficult to spot.
Another case is where CPLAYBOOT (this varies per board, e.g. GEMMABOOT, FEATHERBOOT, TRINKETBOOT) disappears on Windows. This can be caused by installation of the Arduino software which has an old, conflicting driver from 2007. More information on Adafruit: Circuit Playground Express: Troubleshooting.
A very rare case is a mis-seated USB connector. In my case the power was ok but the data wasn't for a good quality cable which had previously worked fine. Unplugging the USB cable at the host end and re-inserting it solved the problem.
the atmega microcontrollers have the internal programmable memory.So the usb flash device write data to internal memory of atmega through spi or it store the program and works as slave?i also want to know can the atmega get program,file in the MicroSD and run without internal memory or it need to run a program in internal disk then including the program in MicroSD?i don't know how the process work in atmega microcontroller.
There are several ways to program the AVR:
Using an external programmer. The Chip is in reset state during this. Then the programmer uses special a special protocol to directly write to the flash inside the controller. This is how your USB programming device probably writes code to the AVR. There are several protocols for this, but the most common one uses the same pins that are used by SPI. You should not confuse them just because of that ;-).
The controller writes the program itself. The chip is actively executing a program. That program on the chip fetches the instructions from e.g. a sd card and using the SPM instruction to copy it to local flash.
The AVR can only fetch instructions from it's own flash memory - you cannot execute directly from RAM or from any other external source.
The best answer for this question you can find at the end or middle of datasheet for AVR device (eg ATMEGA 328P-PU). If you are using some flashing device connected with computer, there is some initialization sequence after start and then there are send some 4 Bytes commands that tels microcontrolers, where to store values to flash and/or eeprom, fuse bits, or cares about erasing etc. There is also posible to read ID of chip.
Atmega microcontroler can be also programmed in paralel mode, where are some bits used for sending commands that tels, what to do with data on data bit.
If you ask about downloading program from SD card or any other device, there is possible to write to the flash through SPM, as there was told above. Some devices do not have part of flash for downloader - if I remember ATMEGA 48, and devices, that have configurable part of memory usable also for downloader, that can handle this, eg. ATMEGA 88, 168, 328. So if you want to download program from SPI, USART, TWI, etc, you need to configure fuse bits and create downloader that will do it for you. I am not sure, how ATMEGA 48 do this, but there si probably possible to write whole flash by SPM instruction.
However the best answer you can find in the datasheet. On pages folowing 255 you can find further information. http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf
I have a project that needs to be compatible with STM32F1s and STM32F4s. I'm starting with a basic project that can use GPIOs and am now trying to get USB HID support. I have USB HID working on STM32F4s with another project using the standard peripheral drivers and USB OTG, but am having a difficult time with the HAL drivers. No matter what I've tried the USB device keeps showing up as an Unknown Device in windows. Where can I best start debugging this issue? Stepping through the code with an SWD makes it seem like the board seems to be working as it should. As far as I can tell the endpoints and descriptors for HID are correct.
Use STM32CubeMX to setup USB for you. Then you need to change the heap size, because the default one is not big enough. For some reason, you cannot change the heap size from STM32CubeMX. To change it, you need to edit the start up file (startup_stm32f4.....s) and find the line:
Heap_Size EQU 0x00000200
and change the value to a bigger one, for example:
Heap_Size EQU 0x00002000
I am working with a simple PIC18F2550 and I'm wondering about how to get a bootloader working on it. It's a very simple device with a USB port and CDC firmware. When I download Tiny Bootloader onto the pic, my PC doesn't recognize the device. Do I NEED to have a USB controller in my circuit in order for it to work? Such as the MAX232?
Would the same apply to the PIC32MX795F512L?
Thanks!
It is clear from the Tiny PIC boot loader documentation that it expects a UART connection rather than USB (that is what the MAX232 is for - it is an RS232 line driver).
You could simply do that and use an external serial to USB converter thus saving the code space required by the USB-CDC stack. Otherwise you will have to modify the boot loader code to use the CDC driver rather than the UART.
You will have to link the USB code with the boot loader, which will no doubt significantly increase its size. You may need therefore also to move the application start address to accommodate the boot loader. Furthermore, if the application needs USB comms, you may need a separate copy of the code in the application unless you provide a method of accessing the bootloader code from the application; which is possible, but not necessarily straightforward.
All that said, note the part at the end of the end of the page about extending the bootloader; On the face of it it seems unsuited to extension. Without looking at the code and its memory map, it is not clear why it has this constraint.
The PIC18F2550 has a USB interface built into it. It is called the "USB SIE" and there is a large section in the datasheet that documents it. If you make the right electrical connections, you should be able to connect your PIC18F2550 directly to a USB port without any active electronics between them. There is no reason you would need extra USB hardware just because you want to run a bootloader.
If you want to troubleshoot your problems with the bootloader, you should probably post another question with more details. It could be a problem with the PIC's configuration bits or something like that. I recommend trying to modify the bootloader to get it to blink an LED as a basic first step just so you can verify that you were able to get its code to run at all.
I'm porting u-boot-2013.10 to MPC8306 based board. Previously, I can erase the first several sectors of Nor Flash using BDI2000. But after sometime, when the porting task is nearly done, (I mean that I can use gdb to trace the code execution and find the u-boot code runs into command line mainloop, though there are no serial output at the time, due to error configure of Serial Port)the first 256KB of Nor Flash can't be erased even if after power off reset. Other sectors can be erased normally.
The Nor Flash is Micron M29W256GL, with block size 128KB. I'm sure the WP# Pin has been pulled high, so there is no hardware protection upon the first block.
When config the jumper on board to change the PowerPC Config Word in order not to let MPC8306 fetch boot code at power up, the problem remains.
I used to run u-boot-1.1.6 on this board, I have erased this version of u-boot so many times without the problem mentioned above. I guess u-boot-2013.10 made some new approach to flash manipulation or others, for example, non-volatile protection on first 256KB of flash.
Is there someone can help me to solve the problem? I would very much appreciate your help.