Hi there,
So far, we found no place where to save persistent M4 configuration and user data after power off. At first we wanted to share some flash regions between M4 and A7 but found no easy way to do so. We ended up placing M4’s configs in DDR and have A7 copy it and save it into flash.
a) Did we miss an easier solution to backup some M4 configs in flash ?
We wanted to share some memory space with RDC and semaphores, yet it seems only the FreeRTOS drivers were developed (RDC_SEMAPHORE_Lock/Unlock) , we found no easy counterpart on linux side.
b) Did we miss something, do you know where we could find such drivers ?
Dear @nicolas.b
a. You are correct. There is no direct way to access the flash memory from the M4. Routing the data through the A7 core is probably the easiest way to overcome the limitation.
Another option would be to use an additional SPI-Flash which could easily be accessed from the M4.
Regards, Andy
Dear @andy.tx ,
Thank you for the quick answer! We considered using an external Flash but in the end that would increase the cost of our solution and we found that having M4 data stored “on A7” is quite convenient to access it with HMI.
We’ll take any help provided on the linux RDC driver matter, thank you !
Dear @nicolas.b
b. I’m not aware of any Linux-side drivers supporting the RDC for semaphores. However, I will ask around withing our Linux team to see whether anyone can help you on this topic.
Regards, Andy
Hi @andy.tx
Got any insight from the linux team ?
Best regards,
Nicolas
Dear @nicolas.b
There seems to be a hardware-semaphore framework in Linux. However, we didn’t verify whether this is usable for the M4/A7 synchronization. Probably you would have to write or extend a Linux driver to make use of it.
The standard way of handing over data between the cores is the rpmsg framework. There are implementations on both Linux and freeRTOS, which allow to send blocks of data from one CPU to the other. By default a block of data has a maximum size of 512 bytes. This can be adjusted quite easily, but requires a rebuild of the source code for M4 and A7.
If this is not sufficient, can you please describe in more detail what the limitations are. Maybe we can give you a better suggestion how to approach your problem.
Regards
Andy
Dear @andy.tx
We know the hardware can handle it for it’s mentionned in the Ref. Manual, but we didn’t know where to find an existing driver for the linux side of the RDC operation and if there was any.
Using Rpmsg on the M4 requires (at least in our use case) the RTOS to be running (Rpmsg has its dedicated task).
As the stored data of the M4 should be used for the initialization of our tasks, we have to retrieve the config BEFORE Rpmsg starts.
Thus we had the idea of using a dedicated space in the DDR as a SharedMemory for our 64kB of M4 boot-time config.
At this point, no semaphore would be really required.
But we also needed to modify this configuration from M4 side while in operation (change baudrate/protocol of a communication task for next boot, …) and read it for display purpose on A7 side. Plus, at some point in the fututre, user could edit it from A7 for next M4 boot !
All things considered, we think it’d be safer to implement a semaphore mechanism to prevent any racing condition. Thus we searched in the RM and found the semaphore possibility in the RDC.
But we only found the FreeRTOS methods, no linux driver.
Last hope : coding our own semaphore mechanism in our applications, either using some DDR bits or a shared GPIO state (we’ve quickly reviewed the SEMA4 example, this could be a solution).
Summing up :
-
M4 and A7 have to share a 64KB (minimum) memory space
-
OCRAM and TCM spaces are used by M4 code and data so we’ll likely use DDR
-
Both cores could access it at the same moment (one writing and the other one reading or both writing) so we need a semaphore mechanism
-
Rpmsg task isn’t started at the time M4 needs the config data
-
We’ve never created nor modified a linux driver so we’d best avoid doing it
We’d gladly hear suggestions on the matter !
Best regards,
Nicolas
@nicolas.b
Sorry for the delayed answer.
As far I know, there is no Linux driver for the RDC Operation.
As the stored data of the M4 should be used for the initialization of our tasks, we have to retrieve the config BEFORE Rpmsg starts. Thus we had the idea of using a dedicated space in the DDR as a SharedMemory for our 64kB of M4 boot-time config. At this point, no semaphore would be really required.
Yeah, this seems to be a good solution.
But we also needed to modify this configuration from M4 side while in operation (change baudrate/protocol of a communication task for next boot, …) and read it for display purpose on A7 side. Plus, at some point in the future, user could edit it from A7 for next M4 boot !
Then you can rewrite this modified Information from M4 to the shared Information and read it from A7 side. I think the edition of this memory by A7 should only be allowed when M4 is not running.
Last hope : coding our own semaphore mechanism in our applications
Make different regions of memory or make sure that the memory is not accessed at same time by the two cores.
Best regards,
Jaski
