I'm writing a small OS for a ARM board, and I'm a bit tired of the usual "remove SD card, copy kernel, insert SD card, switch on" pattern, so I started to look towards u-boot, and now I'm able to load the kernel via serial port using u-boot and kermit: I don't have to remove/insert the SD card anymore.
However this is painfully slow (~5min for 2.5 Mo), and I wonder if I could do the same using the usb port of the board (I know u-boot support tftpt booting method, but I didn't managed to setup the network correctly so far).
Best,
V.
Related
I have an STM32-discovery board and I am trying to program it with not using any cables.In the place where I am doing my internship, they first wanted me to program STM32-discovery with UART. I was able to do this by making the necessary connections and using the Flash loader demo. Now my next task is to add an ESP-07 wifi module on the STM32-discovery board, connect this module to the same network as my computer, and wirelessly program it from my computer. No other device is wanted in between (like Raspberry). I did some research on this topic but couldn't come to a conclusion. What I found; I can remote program by connecting the card to a Raspberry or a device called Codegrip. Is it possible to do this with only an ESP-07 without these devices? I will be glad if you just tell me what should I look for.
Yes, it's possible to reprogram the STM32 flash wirelessly if the STM32 is running a program that supports this capability. When you programmed the STM32 via the UART there was a program running on the STM32 that:
opened the UART port,
received the new program data via the UART (using some protocol),
and then programmed that new data onto the flash.
To do likewise wirelessly, the STM32 will need to be running a program that:
opens the Wi-Fi port,
receives the new program data via Wi-Fi (using some protocol),
and then programs that new data onto the flash.
You may have used the STM32 internal ROM bootloader to reprogram via the UART. And if so then you used the protocol required by that ROM bootloader. But the ROM bootloader probably does not support Wi-Fi. So you'll probably be creating your own bootloader program that can communicate over Wi-Fi. And you might be defining your own protocol for transferring the program data over Wi-Fi. Or maybe you can apply some established protocol such as FTP. Search for examples of bootloaders that support OTA (over the air) firmware updates.
There are two possible solutions.
Write a custom bootloader for the STM32 - the flash is organised with smaller blocks at the start to support that, so you would move your application to higher memory and have the bootloader either jump to the application to load a new application. The bootloader can then access the Wi-Fi module (and other interfaces) to get updates.
Write custom firmware for the ESP0-07 so that it receives and stores the STM32 image, then transfers it to the STM32 using the existing ROM serial bootloader. In this case you need the details of the bootloader protocol, and it would be useful if the ESP-07 had a GPIO connection to the STM32 reset line so that it can invoke the bootloader without a manual reset.
Either way, you need to write software for one or other of the devices.
You can use any standard bootloader and connect the Wireless module like ESP32 (Bluetooth and Wifi), ESP8266 (Bluetooth and Wifi), BT-05 (Bluetooth), HM-10 (Bluetooth), etc.
Then create the android application or web application and update the Firmware or application.
If you don't want to use the Standard Bootloader, you can implement your own bootloader and add this OTA feature to that.
We have added the Tutorials step by step. Please refer to this if you get time. There we have developed the custom bootloader and updated the Firmware.
I have and issue that the only way the FPGA on a myRIO Module runs is if it is programmed over USB. It does not run after powering down and back up. It does run after unplugging the laptop after it has been programmed over USB. I suspect that not running after a power cycle is because the FPGA is only getting the image loaded internally over USB.
Is there some special LabVIEW command to program the serial flash on the FPGA so that the FPGA runs at powerup, or does programming the FPGA over USB always program the serial Flash?
Do you have just FPGA part, and no Real-Time application? In case of just FPGA part, it is enough to build bitfile, and then deploy it (actually, upload it to myRIO and set to run at boot). Here is Knowledgebase article from NI about how to achieve it.
In case when you also have Real-Time part, then it should be also deployed, and set to run at the boot. Here is another detailed article about how to configure it: Deploy a Startup Application to Your MyRIO.
I made a STM32F042k6, battery powered device, that I would to flash vi DFU protocol.
In order to do so I disconnect the battery, I pull BOOT0 to VCC, and then plug the device in USB3 port of PC (no USB2 available). The device is not recognized and showed
VID:0000 PID:0002 (case I)
However, when I first connect battery, and then connect the device to PC it is recognized without a fuss (case II).
The problem I face is that I would like to initiate jump to bootloader program by command in software - but then I reach exactly the same condition as in case I.
Could you help me to identify what conditions for proper boot I am violating?
EDIT:
The way I have discovered the problem was when I implemented software jump to bootloader. It seemed not to work at all (VCP device dissapeared, and erroreous <> device appeard in system PID:0002 VID:0000).
I wanted to enter bootloader by pulling up BOOT0 pin, but I could see that I sucseed only when battery-power cycled. USB power cyccle resulted in the same "failed descriptor" device.
I suspect that when powered on via USB, the booloader has som ecommunication problems and cannot establish proper PID and VID. When powered via battery - this problem is not existing.
Do you have a discovery board?
I read in the STM32F042x4/x6 Reference Manual (DocID025832 Rev 5):
The STM32F042x4/x6 embeds a full-speed USB device peripheral compliant
with the USB specification version 2.0.
(part 3.19, p.27).
In the AN2606 (Rev 33), a table shows the USB configuration which is used by the DFU Bottolader in USB FS (Full-speed):
I assume that the USB in the bootloader is the 2.0, but USB 3.0 must be USB 2.0 compliant. So it is possible to use an USB 3.0 port.
I suggest you use the DfUSe Demo from ST. Its interface consists of a tab where the DFU devices available are displayed when detected. I try it on another STM32x by following these steps:
Open DfuSe Demo software.
Plug BOOT0 to Vdd to put the micro on DFU mode.
Plug the USER USB to your computer port.
The name of your device should appear in “Available DFU Devices” field.
You could try to use directly PA11 and PA12 as well (according to Table 12) instead of the USB port of your board.
EDIT:
Another solution to upgrade your firmware without driving boot0 is to jump directly into the DFU bootloader of ST inside your firmware. Else you could design your own IAP bootloader (In-Application Programming).
I hope that helps.
I faced this same issue with the STM32 Mini F401 and dug into it for several days. Unlike the OP I was unable to find any electrical conditions which reliably got the bootloader to do the right thing. I was able to program my board maybe once every 20 tries, which was really slowing down my process.
In the end I discovered that I can go to the Windows device manager, show hidden devices, and there will be an entry in Universal Serial Bus Devices called STM32 BOOTLOADER. When the issue is happening the board is connected in dfu mode but that device is not marked active in the device manager.
To resolve the issue consistently, you can manually delete the hidden STM32 BOOTLOADER entry, uninstalling the device (no need to delete the driver, just uninstall the device). Then reboot your board in DFU mode and it should connect as expected every time. Unfortunately I need to do this process every time I want to program, but that's far better than the inconsistent/intermittent failures before.
I have a STM32373c-eval board and just getting started.
I have installed Truestudio, CubeMX and ST flash utility on my ubuntu 16.04 cause I don't have access to Keil or a Windows PC.
Using CubeMX I generated a code for LED toggle and it worked fine.
Now I did the same for USB CDC - checked the Device(FS), RCC clock at High Speed (Crystal) and
under Middlewares I have set Communication Device Class (COM Port) for Class For FS IP and USB clock is at 48Mhz.
I did no modifications in the generated code just flashed it and connected the kit to my Ubuntu alas I don't see the enumeration.
I also checked for any jumper settings for USB but there ain't any.
Can any one help me out in this regard?
Thanks.
I would like to have some kind of mechanism to somehow load the RAM on the Raspberry Pi programmatically from a controller computer (I assume through the SD interface) and then let the Raspberry Pi's CPU execute. Is there some kind of device that does this? And what is it programmed in?
It would also be great if there's a way to interrupt the whole thing from the controlling computer if needed.
SD is a fairly poor choice for an interface to try to push data into from an external source; generally the computer hosting the SD device wants to be the master of operations.
But the Raspberry pi has both uart serial ports and (on the model B) an ethernet interface. Downloading code through either is quite normal.
You haven't mentioned if you want to run an application atop a typical linux installation, or if you want to do bare metal programming. In the first case you would typically transfer the program to the file system (either ramdisk or the SD card) and then execute it.
In the second case, you would need a stub of code already on the device (which is to say, the boot partition of an sdcard) which knows how to configure peripherals sufficiently to enable reception of code via serial or ethernet (the latter complicated by needing a USB host stack), and then jump into it.