Dear NXP Support Team,
I am working with NXP Model-Based Design Tool (MBDT) v1.6.0 and I have a question regarding the DataMemRead block.
I would like to read data from a memory address that is provided by a variable at runtime (i.e. a dynamic address / pointer). However, the DataMemRead block in my version does not expose any input port for the address; the address can only be configured as a fixed parameter in the block settings.
My questions are:
Is it possible to use the DataMemRead block with a variable (dynamic) address in MBDT v1.6.0?
If not, is this a known limitation of the block?
Is there a recommended or supported alternative within MBDT to perform memory reads using a variable address (e.g. via a specific block or a recommended C Function/User Code approach)?
Any guidance or best practices would be appreciated.
Thank you in advance for your support.
Best regards
Hello, thank you for the clarification.
To confirm, in our use case the data that needs to be accessed dynamically is stored in RAM, not in Flash. The address is calculated at runtime and must be dereferenced dynamically.
Given that dynamic RAM addressing is not supported by the current Model-Based Design Toolbox implementation, could you please advise:
- What is the recommended workaround for this use case?
- Is the expected approach to use a custom C block / S-Function for dynamic RAM access?
- Are there any roadmap plans to support dynamic RAM addressing in future toolbox releases?
This functionality is required for our application, so any guidance on an NXP-supported or validated solution would be highly appreciated.
Best regards,
Hi, @mariaalejandro,
Thank you for your interest into Model-Based Design Toolbox for S32K3.
If the data that needs to be accessed dynamically is stored exclusively in RAM, the current version of the block does not provide a solution that supports this use case. Dynamic RAM addressing is not supported by the existing implementation.
If the data is stored in Flash, it can be accessed using the MemInFls Read block, which does allow the use of a dynamic address as its input. The limitation, however, is that the data must already be written to Flash beforehand in order to be selectively accessed (read) at runtime. You can refer to the following model example: s32k3xx_mem_infls_s32ct, where for the Source Address is used a Data Store variable.
Best regards,
Dragos
Hi, @mariaalejandro,
Since this feature is not yet supported by the toolbox, I’ve outlined below how you can approach the topic using custom code. You can use the s32k3xx_dma_transfer_ebt model example as a starting point for integrating custom code.
1. The first step would be to create a folder containing the .h and .c files, that you will use to create your custom functions. This folder and the corresponding files should be included in the Hardware Settings of the model, at Custom Code section:
- Include directories
- Source files
2. The next step would be to define these newly created files.
- dmaBuffers.h will contain the directRAMRead and directRAMWrite function calls:
- dmaBuffers.c will contain the diretRAMRead and directRAMWrite function definitions:
3. The model example should contain the MATLAB Function block for creating the environment of calling the already created functions.
Please note that in the above example was used uint32 as a data type, you should modify this based on your project requirement.
4. After building and deploying the code on the hardware, we must validate the model example by importing the generated code into S32 Design Studio IDE. The step function will look like this:
If you enable the Memory section in the bottom right side in S32DS, you should be able to see the addressed, based on your selected monitors. For example, the 0x20004000 address has been selected, considering the hardware part that the model has been validated on:
At this section address, a random data has been written. After continuing one step in the debug process, allowing our read function to be executed, the returned result will look like this:
The difference between the written value (00001234) and the value observed during the memory read (34120000) is a direct consequence of the system’s endianness. The target platform uses little‑endian byte ordering, meaning that multi‑byte values are stored in memory with the least significant byte (LSB) at the lowest address.
So when the logical 32‑bit value 0x00001234 is written, it is placed in memory as:
| Byte position | Stored byte |
|---|---|
| Address + 0 | 0x34 |
| Address + 1 | 0x12 |
| Address + 2 | 0x00 |
| Address + 3 | 0x00 |
When the memory is read back as a 32‑bit word, these bytes are reassembled in the correct order by the CPU, resulting in the displayed value 0x34120000.
This behavior is expected and correct for little‑endian architectures. The model example simply reflects the underlying memory representation, not an error in the input or the tool.
I have also attached the archive containing the model example used in the demonstration.
Hope this helps,
Dragos