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
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
