I created a firmware for M4 core of VF61 and I tried to load it from A5 running Win CE 6.
I slightly modified Rpmsg_Demo example supplied with ToradexCELibraries 2.0-20170524 to match my firmware
//Firmware load address, must use system bus address, please go through this link(http://developer.toradex.com/knowledge-base/freertos-on-the-cortex-m4-of-a-colibri-vf61) for more information.
returnValue = Rpmsg_SetConfigInt(hRpmsg, L"LoadAddr", 0x3f000000, StoreVolatile);
//Firmware code block size
returnValue = Rpmsg_SetConfigInt(hRpmsg, L"CodeSize", 32*1024, StoreVolatile);
//Read ELF format and get entry point execution of the address, must use code bus address. please go through this link(http://developer.toradex.com/knowledge-base/freertos-on-the-cortex-m4-of-a-colibri-vf61) for more information.
returnValue = Rpmsg_SetConfigInt(hRpmsg, L"ExecuteAddr", 0x1F00163b, StoreVolatile);
I’ve just been informed that the bin file I attached to the first message works as expected when it’s loaded from A5 running Linux.
For this reason I think the issue is related to Win CE 6 and/or the library used to load the firmware.
It’s just an idea, but maybe Win needs to clean in some way the memory before loading the firmware? If Linux loads the firmare from the U-Boot maybe this is not necessary.
We tried here, it didn’t create an exception. Could you please share call stack. So that, we can easily know which function from the application is generated an exception.
If you are not using any communication channel on M4 firmware side, please don’t call RxThread on Rpmsg_Demo application.
It’s really strange.
Today the same firmware doesn’t generate exception anymore.
The “new” behavior is that the connection with A5 core (AcriveSync) is immediately lost and I can see that the display connected to the Colibri Module shows mixed random colors.
Is this the same behavior that you see?
When we run the firmware with Rpmsg_Demo application, we are seeing
“Failed to create communication channel” error with this library version but could not reproduce the exception issue.
I have tested it Colibri VF61, WinCE6 V1.4.
Could you please confirm are you getting the same behavior?
Hi @raja.tx,
after a deep investigation with Keil, it seems that all the strange behaviors just after the load (crash, exceptions, …) are related to semihosting not properly disabled.
Semihosting is a word used by Keil, and it means that all the accesses to I/O (printf, …) are redirected to the host computer through JTAG connection.
Semihosting is enabled by default when you compile with Keil.
A firmware can be loaded and executed standalone only if semihosting is disabled.
If I disable properly semihosting, I don’t see any strange issue just after the load, and I can recompile and execute properly rpmsg_example supplied by Toradex in Keil DS-MDK 5.27.
This is a great success (compared to all the issues I had in the past).
Now I have different problems, but the issue in this thread can be closed because the reason is that when you compile with Keil, semihosting must be disabled following this document on Keil website.
Hi @raja.tx,
after a deep investigation with Keil, it seems that all the strange behaviors just after the load (crash, exceptions, …) are related to semihosting not properly disabled.
Semihosting is a word used by Keil, and it means that all the accesses to I/O (printf, …) are redirected to the host computer through JTAG connection.
Semihosting is enabled by default when you compile with Keil.
A firmware can be loaded and executed standalone only if semihosting is disabled.
If I disable properly semihosting, I don’t see any strange issue just after the load, and I can recompile and execute properly rpmsg_example supplied by Toradex in Keil DS-MDK 5.27.
This is a great success (compared to all the issues I had in the past).
Now I have different problems, but the issue in this thread can be closed because the reason is that when you compile with Keil, semihosting must be disabled following this document on Keil website.
