I had flashed Intel's pre-built src images on board by replacing u-boot.elf compiled with buildroot(having support for Edison board).
But the board is stuck on FSBL(FSBL watchdog is continuously rebooting the board). I tried to flash on board, but on board no listener is present to serve flash operation (usually done by dfu utility in u-boot).
So that I am not able to flash pre-built images again.
By this present conditions, how can I bring my board up?
How can I flash images again?
INPUT :
Board console o/p
******************************
PSH KERNEL VERSION: b0182b2b
WR: 20104000
******************************
SCU IPC: 0x800000d0 0xfffce92c
PSH miaHOB version: TNG.B0.VVBD.0000000c
microkernel built 11:24:08 Feb 5 2015
******* PSH loader *******
PCM page cache size = 192 KB
Cache Constraint = 0 Pages
Arming IPC driver ..
Adding page store pool ..
PagestoreAddr(IMR Start Address) = 0x04899000
pageStoreSize(IMR Size) = 0x00080000
*** Ready to receive application ***
In FSBL, is there present any kind of "dfu utility"?
Any help will be appreciated.
For installation fstk, I had asked question for the same.
Kindly refer Question mentioned below.
Install XFSTK in ubuntu 16.04
Along with this, prebuilt bins are received for recover edison board
Related
The ESP32 flash command, as executed by the Arduino IDE, seems to flash two bootloader files: boot_app0.bin at offset 0xe000 and bootloader_dio_80m.bin at offset 0x1000. I wonder what these two bootloader files actually do, and why there are two of them. Below I give some more information.
1. Context
I'm part of a team developing a new, free IDE for microcontrollers: Embeetle IDE. We're planning to support the ESP32 microcontroller family in the near future. Therefore, I'm now studying the ESP32 build system - both the ESP-IDF tool and the Arduino IDE approach to ESP32 projects.
2. Arduino IDE flash procedure for ESP32 projects
After building the .elf file, the Arduino IDE launches a command to convert it into a binary:
python esptool.py --chip esp32 elf2image
--flash_mode dio
--flash_freq 80m
--flash_size 4MB
-o /tmp/arduino_build_852524/WiFiScan.ino.bin
/tmp/arduino_build_852524/WiFiScan.ino.elf
Finally, this WiFiScan.ino.bin file is flashed to the board, alongside two bootloader files and the partitions table:
python esptool.py --chip esp32
--port /dev/ttyUSB0
--baud 921600
--before default_reset
--after hard_reset write_flash
-z
--flash_mode dio
--flash_freq 80m
--flash_size detect
0xe000 ~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin
0x1000 ~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin
0x10000 /tmp/arduino_build_852524/WiFiScan.ino.bin
0x8000 /tmp/arduino_build_852524/WiFiScan.ino.partitions.bin
The default partitions table, as used by Arduino IDE, looks like this (in csv format):
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xe000, 0x2000,
app0, app, ota_0, 0x10000, 0x140000,
app1, app, ota_1, 0x150000,0x140000,
spiffs, data, spiffs, 0x290000,0x170000,
The binary equivalent of this csv-file gets flashed to address 0x8000. There are also two bootloader files being flashed to addresses 0xe000 and 0x1000 respectively (see next paragraph).
3. Bootloader files
The two bootloader files being flashed are:
# flashed at 0xe000
~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin
and:
# flashed at 0x1000
~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin
Question 1: What do these two bootloader files do?
It's also interesting to observe their locations. The first one, boot_app0.bin is located in a folder named 'partitions'. It sits there alongside several partition .csv files. Why? But maybe that gets clear when Question 1 is answered.
The other one, bootloader_dio_80m.bin is located in a folder named 'sdk/bin/' and sits alongside other files that all start their name with the 'bootloader_' prefix:
Question 2: As for the bootloader file flashed at address 0x1000, I think the '_40m' and '_80m' suffixes stand for the flash speed in MHz. But I've no idea what the '_dio', '_dout' and '_qout' suffixes stand for.
Please enlighten me ^_^
Answer
Thanks to #Juraj, I now get a better insight into the startup procedure of an ESP32 chip. I believe it looks like this:
FIRST STAGE BOOTLOADER:The hardwired ROM-bootloader runs first. This first stage bootloader is outside the Flash memory and cannot be programmed. It loads the second stage bootloader (see next step).
SECOND STAGE BOOTLOADER:The first stage ROM-bootloader loads the second stage ESP-IDF Software bootloader at address 0x1000 in Flash. The code here is the bootloader_dio_80m.bin executable, which can be found in the components/bootloader directory of the ESP-IDF framework.
This second stage bootloader reads the partition table found by default at offset 0x8000. If OTA app partitions are found in the partition table, the bootloader consults the ota_data partition to determine which one should be booted.
BOOT SWITCHThe ota_data section can be considered as merely a switch, located at 0xe000 in Flash. It determines if either app0 or app1 should boot. The switch itself is the boot_app0.bin binary. As Juraj says, the 2kB size is also used to take notes during OTA flashing.
APPLICATIONThe application at app0 or app1 executes.
Thank you also for pointing me at these resources:
ESP32 bootloader
ESP32 startup procedure
The binary at 0x1000 is the bootloader. Arduino ESP32 has bootloader binaries corresponding to boards options in Tools menu in Arduino IDE (built from boards.txt).
The bootloader functions are documented here.
The ESP-IDF Software Bootloader performs the following functions:
Minimal initial configuration of internal modules;
Initialize Flash Encryption and/or Secure features, if configured;
Select the application partition to boot, based on the partition table and ota_data (if any);
Load this image to RAM (IRAM & DRAM) and transfer management to it.
The boot_app0.bin is the OTA data partition initial content. It is documented here.
The OTA data partition is two flash sectors (0x2000 bytes) in size, to prevent problems if there is a power failure while it is being written. Sectors are independently erased and written with matching data, and if they disagree a counter field is used to determine which sector was written more recently.
DIO, QIO, DOUT, QOUT are SPI modes for the flash memory. Different esp32 modules have different flash memory chips and their connection. (D is double, Q is quad)
I'm trying to burn the bootloader to an ATMEGA328P - AUR, the 32-pin SMD variation with my Arduino Uno. I've tried the recommended way that the Arduino website suggests to burn the bootloader. However, I don't have the 16MHz crystal recommended, so I tried the workaround method they describe to use the internal 8MHz oscillator. Burning the bootloader gives me the "Yikes! Invalid device signature" error. Do you think there is an incompatibility with the chip? Problem with using the internal oscillator? Should I just get the crystal?
For just invalid device signature - (this usually occurs if internal clock is on)
For the ATMEGA328p if it is preloaded with a bootloader for some reason there is a mismatch in signatures so you'll have to do this THEN UNDO IT << please don't forget or else you'll have to bootload everytime before you write a script until you UNDO this.
You'll want to open up the avrdude.conf file in Arduino's program files
for mac: show package contents for PC and Linux just search the Program Files
in this file search for " ATMEGA328P " under it should be a field named signature replace "0x1e 0x95 0x14" (the 328 signature) with "0x1e 0x95 0x0F" (the 328p signature)
Follow step 2 - 4 below, if this works you're all set.
if internal clock is not on a sync error occurs
The ATMEGA328p has an internal oscillator which operates at 8MHz but this oscillator is apparently turned off when the a 16MHz bootloader is burned to it. So if you are gonna burn an 8MHz (lilypad) type bootloader to it you'll have to do so with the 16MHz oscillator in place so the internal clock can be turned on.
To do this:
load ArduinoISP example script on the UNO R3 that you're going to be boot loading with
(Configure in Tools > Boards > LilyPad Arduino or ATMEGA328 on breadboard)
(Configure in Tools > Port > ArduinoISP)
Afterwards you should be ready to burn boot loader
if sync error persist it means that the clocks are missaligned meaning you've got to slow down the boot loader
in the Hardware folder search for a boards.txt file within the avr folder
edit the line in the file containing "atmega328bb.upload.speed=57600" to read "atmega328bb.upload.speed=19200"
try steps 2 - 4 just above again
Try each of these steps in various combinations or appropriately as the problem evolves. If this doesn't seem to work just continue search forums... I had found all this in about 3 hrs on google - good luck!
Recently I got my ESP 8266. It was running fine untill I hit the command AT+CIUPDATE for installing any OTA updates. The module is now unresponsive. It returns garbage values in the serial monitor when powered and connected to Arduino Mega.
Can any one help me out in this problem?
The binaries become corrupt due to heating, to restore it to its normal state, use any flasher tool to re-flash the firmware onto it.
I purchased a BLED 112 dongle from BlueGiga (http://www.bluegiga.com/BLED112_Bluetooth_smart_dongle). I purchased the dongle since I was trying to do a simple POC with an iPhone. I did not want to get into breakout boards or the dev kit just yet.
I am trying to get the heart rate monitor samples working and I am not sure how to load the firmware on the device. I am using the latest version of the SDK (v1.1.1) which states to use the BLE Update tool, not the TI Flash Tool.
However it looks like you need the CC Debugger with the BLE Update Tool to update the SOC. I looked at the CC Debugger and it does not appear to be designed to be used with BLED 112 USB dongle. It appears you need a breakout board to expose the pins to be able to hook the CC Debugger to a BLE 112 module, not a BLED 112.
Lastly, I am not sure if DFU will work without bricking the dongle.
Any advice on how to properly use and program the BLED 112?
Thanks,
G
From the SDK docs:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK
v.1.1 or newer, but BLE Update tool should be used instead. The BLE112
and BLE113 and BLED112 devices contain a security key, which is needed
for the firmware to operate and if the device is programmed with TI
flash tool, this security key will be erased.
It is possible to update the firmware on the BLED112 via the USB connection, and without requiring a breakout box or a CC Debugger. However, it is fairly easy to accidentally 'brick' your device in so doing. The problem is that the firmware itself needs to provide the interface to enable DFU mode; if you do an update with your own firmware, and your firmware doesn't provide this capability, you're stuck with the last thing loaded on it.
That being said, here's the process.
The BLED112 dongle is essentially just a BLE112 with an attached USB connection. The BlueGiga SDK ships with drivers that allow the device to be mapped with a simple serial interface, such that the device shows up as a simple COM port (e.g., "COM16") to applications running on the host PC. The SDK also ships with two utilities - BLEGUI, and DFUTOOL - that are able to use this COM port interface to communicate with the device.
(Getting the drivers installed seems like it should be easy, but the process was finicky for me, and I ended up having to mess around with Device Manager, etc., for a while before getting the COM port to show up reliably when I attached the dongle.)
The basic process for building and installing firmware on the BLED112 is:
Compile your BGScript program to an image file using BGBUILD.EXE
Reboot the dongle into firmware update (DFU) mode using BLEGUI2.EXE
After attaching to the appropriate COM port, select Commands | DFU from the menu.
Update the firmware using DFUTOOL.EXE
Before you do this, make sure you read the "Developing Bluetooth 4.0 single-mode applications" and other technotes from BlueGiga's forum (registration required). Specifically around your project configuration:
WARNING:
If the firmware is to be installed into the BLED112 USB dongle the USB
CDC configuration MUST BE included in the project file. If this is not
included in the project file and the compiled firmware is installed
into the BLED112 USB dongle, the USB interface will be disabled and
the dongle stops from working.
Phew. Not necessarily for the feint of heart. I personally found it more appealing to shell out the money for the DKBLE112, which has the BLE112 module mounted on a board with some other accessories, and a CC Debugger for programming. With this setup, you can flash new images to the chip without worrying so much about screwing things up (there's a "reset" button on the board itself).
Other people have reported using breakout boards that are cheaper than the DKBLE112, such as this one from Jeff Rowberg. They also let you program with the CC Debugger, but I have no experience with them.
Have fun!
Based on the information provided, I found the following technote on the BlueGiga support knowledge base.
https://bluegiga.zendesk.com/entries/22810076--HOW-TO-Run-a-BGScript-application-on-the-BLED112-USB-dongle
Thanks
Greg
I have a problem with Windows CE 6 and a DIGI device with processor Freescale IMX51. I wrote an application in C # using the BSP of DIGI, to use the ARM eSPI (enhanced Serial Peripheral Interface).
Then using the functions issued by DIGI, in debug, I can active a OLED using SPI, but when I launch the application on the device, the OLED no longer works.
I have seen with an oscilloscope that when I load the application in debug mode the number of bits is correct, i.e., the clock has 8 rising edges, but when the application is launched from the device, the clock increases somewhat, that is, I see 9 bits. This also happens when I use the .exe from the debug directory.
I do not understand why this is happening. Can anyone help me solve this problem?