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.
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.
There is 1.6 MB of external storage shows when we connect Nucleo to PC. Can we access that storage to save or read files from it from application i.e. in code? I haven't found any particular solution anywhere so asking here.
Except the "major" MCU for application, there is another MCU on the Nucleo board works as a programmer (ST-Link). This auxiliary MCU is connected to the application MCU with an UART for virtual com port, and a SWD for programming. That 1.6 MB of external storage you see on PC is emulated by this programmer MCU, and the firmware in this MCU has no simple way to be modified (suppose you still need it to act as a functional programmer and VCP). So the answer to your question is no simple way to do that, unless you are willing to sacrifice the programmer functionality of the auxiliary MCU and write a protocol to access the emulated storage on that MCU.
The mass storage device presented is not real, it is presented by the Nucleo bootloader/debugger interface chip as a simple drag-and-drop means of programming without additional software on the host PC. It is a means of programming the on-chip flash of the STM32 and is not external storage.
I have a project based on a Nucleo H743ZI2 board that communicates with a PC through the USB OTG port on the Nucleo.
Everything is working fine as long as, weirdly enough, I have the STlink USB cabled plugged in (which I have been using to work on the firmware, flash, debug, etc).
However, today I was getting ready to do actual tests with this project and used an external power source to power the H7. I initially tried a 3.3V external source which is available from one of the shields, and then tested a lab PSU at both 3.3V. Thinking it could be PSU related I also tried external 5V with the same results.
Basically, the device is not recognized by the computer operating system, unless the STlink USB is plugged in.
I can't really put my finger on this one; I initially thought it was a PSU related issue (that nucleo board has some restrictions when it comes to using external power sources) but at this point I am fairly confident I am failing to initialize something in my code. Not sure what though.
I'd be happy to share with my code, but wouldn't know where the start. I haven't done much as far as the USB OTG is concerned other than modifying the receive callback to process the data.
Any idea what I might be missing here?
Cheers
we are planning to use stm32f4 discovery board in our satellite.we will have a code backup in the sd card.How to dump the code on to the Microcontroller when there is a code corruption.
You need to write a bootloader that has access to the SD card peripheral which will read the backup code off of the card and program the flash program space on the STM32 itself (assuming this is where you are running the code from).
There are plenty of resources on bootloading the STM32. Here are just a few
STM32 microcontroller system memory boot mode
Make own bootloader for Arm Cortex-M3
You need boot loader to do your work. You may choose to use the example boot loader that STM provided or your can write your own boot loader.
The flash you reserve for the bootloader must be a whole number of flash pages starting from the reset address , After that you will have to rebuild your application code for the new start address because current start address has bene taken by Bootloader.
I've been looking at QEMU for a while now and I've been trying to find out if I can use it to simulate a device that we are developing.
The device will be powered by an ARM Cortex M3 and QEMU is well suited for emulation of its software.
What I want to know is if anyone has used QEMU in the past as a simulator?
The intent is to use QEMU to do black-box testing of the software before rolling it out to the devices in the field.
This would involve being able to monitor and modify the memory location in which your Parallel Input/Output (PIO) pins are configured and set and the memory locations of all other peripherals externally.
Now, considering that some of the peripherals would be PWM and UART, it is clear that there will be a need to resolve synchronization issues. However, I would like to avoid this topic for the time being and stick only to simple PIO.
The QEMU Monitor gets close but is not quite there yet.
So to summarize:
I need to know if there is a way to interrupt QEMU after each CPU clock cycle and read/write to a small number of memory locations in the code memory.
Did you try to use GDB stub ? You can use -s -S and connect through gdb by target remote :1234. This will give you control over program executed inside vm and access to registers and memory.