Ifollowed the instruction guide on the "Getting Started with MCUXpresso SDK for EVK-MIMX8MP" under the section 4 "Run a demo application using IAR". Once i reached the download and debug stage, my IAR IDE prompt me this - Missing or malformed flash loader specification file:C\Program Files\IAR Systems\Embedded Workbench 9.1\arm/config/flashloader/
This method you mentioned we had tried before posting this issue on this forum. Apparently, the default setting under Project->Option->Debugger->Download - the checkbox "Override default.board file" is already "unchecked" in the first place. We also tried checking onto the checkbox to see if it works. Turns out checking and unchecking of the checkbox "Override default.board file" doesn't work at all
Not sure if there are other methods to go about this. Just trying to conduct a simple run of "Hello World" application example on the M7 core, i am already facing such technical issues. Hopefully there are other methods you propose, or others propose can work.
I have had some success following the "MOOC - External QSPI loader how to" youtube video series by ST and the example code for memory mapped QSPI available in the "STM32Cube MCU Package" downloaded from ST website.
However, when I use the created External loader (based on the example code and video series) I am able to read the FLASH using the STM32 CubeProgrammer, but the first 2 bytes are always 0 even when the flash has been erased only.
I did actually find the examples you mentioned which look very similar to the "MOOC - External QSPI loader how to" video series done by ST referenced from original post. Also, I have attached a log-file from STM32 Cube Programmer with "Verbosity Level 3" to the original post.
If I use the STM32 ST-Link Utility v 4.5.0.0, open the file RAK5205_Blink.hex and program the MCU, it ends correctly and the program runs without problems on the board. If I want to completely erase the Flash memory, it does it correctly with this indication:
Now, if I open the STM32CubeProgrammer v2.1.0, open the same file RAK5205_Blink.hex, the ST-Link v2 is recognized and connected correctly, read the memory of the MCU without problems, but when I want to program it in the same way than before, it shows the error, "Flash loader can not be loaded".
You must disable the read protection. The easiest way to do this is with the ST tool "Flash Loader Demonstrator". After a few next clicks you will find the option "Disable Read Protection" there. After that, you can check the "Option Bytes" with the STM32 ST-Link Utility. After that debugging ist running like a charm.
I have no idea, what the source of this error might be. Since flashing and executing the program are both working fine after using the older ST-LINK Utility, the issue should be located inside the Toolchain / STM32CubeProgrammer.
No solution for the exact error. However, I did confirm with the factory that in using the PFL IP utility and generating VHDL, it would not work correctly. I used the PFL IP utility and generated a schematic block and got it working. Seems to be a bug in code generation. I moved on. Sorry I am no help. Maybe someday someone will find an answer to this. I have seen that many have had the same problem.
Thanks for the reply. My issue turned out to be a dumb user error... I had the flash_data pins as outputs rather than bidirectional IO. I don't know how I missed that, but, once corrected it worked like a charm.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
The application project illustrates the flexibility of the Flashloader and shows how an example solution can be easily integrated. It guides developers on how to review, configure and customize the major software components, and update the example to fit nearly any requirement.
After installing, you can find two interesting executable files (depending on where you installed it, typically in the "STMicroelectronics\Software\Flash Loader Demo" subdirectory): STMFlashLoader.exe and STMFlashLoader Demo.exe. The first one is a commad-line utility, second has a GUI interface. Command-line is good for integrating into your IDE / toolchain, for example Eclipse.
There are parameters that you need to adjust to match your environment. For example "--pn" is the number under which the usb-to-serial virtual COM port appears in your computer. You can find this out for example in Control Panel -> Device Manager -> Ports (COM & LPT), in my case the port is COM43:
The "--a" parameter is base address (in hex) where to flash the "application.bin" (an arbitrary filename your code was compiled into). This is typically 0x08000000 to get the file into the beginning of the code space, so it starts executing on reset, however if you are uploading other data (e.g. sound samples) you may want to change this address to point somewhere higher in the address space. In order to convert ELF file to BIN use the objcopy.exe utility, which should be present in your toolchain directory - with TrueStudio it is usually in "ARMTools\arm-atollic-eabi\bin\". Usage is:
These operations can be combined, for example the next command will first erase memory and then flash the binary. Not entire memory is erased (that would be "-e --all" option as in global erase example), it is sufficient to erase only the sectors your binary code spans across (in our case the first, or "0-th" sector as they are numbered from zero).
Please see the 3rd screenshot from GUI utility below which shows FLASH memory map, sector numbers and addresses. For example, if your binary is larger than 32kB but smaller than 48kB, you need to erase first 3 sectors.
Click "next" again. Now the utility displays the FLASH memory map for your MCU. The 1MByte space is usually divided into 11 sectors of various sizes (4x16kB, 1x64kB and 7x128kB). This is important as one sector is the minimal space which can, and must, be erased at once (while programming can be done gradually, it is only possible to flip bits from 1 to 0, erased space reads as 0xFF).
Click "next" again, now you can choose the desired operation and/or a binary file to flash. With blank MCUs it is not necessary to erase anything at all. When re-flashing the binary, it is sufficient to only erase necessary pages - the utility will determine which sectors need to be erased automatically, based on binary file size.
If everything went well, you should see this result, otherwise retry some of the previous steps - together or separately. Due to FLASH memory being slow, you may sometimes get warnings/errors related to erasing the memory, even if everything went well. In such case, next time try to flash the binary with "No Erase" option selected.
I am using IAR 8.42 with a PE Micro debugger. If I debug a project (call it project A), the linker ROM space starts at 0x0, I can program a device with the debugger, and run and step through the code.
Hi, I don't have a PE Micro to test with, unfortunately. I tried to replicate this with the regular J-link by adding automatic loading of the Softdevice in a BLE example then went back and debugged the blinky example starting at 0x0, but the Softdevice got overwritten successfully so didn't encounter any problems with debugging.
The problem in your case appears to be that the debugger fails to erase the MBR section of the Softdevice at address 0 for some reason. Does the PE Micro have a separate programming utility you can use to perform a chiperase? Alternatively, give you register access so you can do the "Erase all" manually?
Also, it may be worth trying to update to the most recent MDK release in case it includes improvements to the flash loader. It's available for download at -and-tools/Development-Tools/nRF-MDK/Download#infotabs
I am not able to get the ST Flash loader to recognize the STM32 on the MP32. I get the following error: "No response from taget, the Boot loader can not be started. Please, verify the boot mode configuration and the flash protection status ...".
Regarding B, this seriel configuration is working when I connect to either of the usarts on the StmDiscovery board. In fact on the discovery board, with respect to usart#1, I am connecting to pins Pa9 & Pa10 (same as MP32).
I am noticing that when I press next on ST flash Loader I can see the Tx and Rx blip momentarily, and then the Rx led on the 232-ttl converter stays on slightly dim (until I press the reset button on the MP32).
I tried several different buad rates in Flash Loader, but didnt have any luck. Also, I tried all the above on my deskop (which has serial ports). I used the same level shifter at the end of the cable. In all the above I also tried switching the Rx and Tx going to the MP32 (in case I had them backworks)s. I even tried pressing the reset after powering the board up, before trying the use the Flash Loader.
The only thing I didn't think of until now (editing post) is that on the Discovery Board I powered the 232=ttl convertor at 3.3. When connected to the MP32 it is being powered at 5. What level is the usart at?
I am having a problem communicating with my board using flash bootloader. I am designing a breakout board for the STM32F103RB, I have the UART1 pins out so I can use flash programming rather than JTAG, but I am having no luck with ST flash programmer it gives me different problem messages..
1) "Unrecognized device...please, reset your device then try again"
2) "No response from the target, the boot loader can not be started. Please verify the boot mode configuration and the flash protection status, Reset your device then try again"
3) "Cannot get available commands, please, try to change echo selection, reset your device then try again"
Board:
====
I have a custom made board, which I confirm is working since I have the JTAG pins out as well and was able to connect and program it using Olimex ARM-USB-OCD + Eclipse
3a8082e126