Is it possible to use custom defines in MCUXpresso Config Tools?

[mitterha]

Hello,

to make the resulting code from MCUXpresso Config Tools a little bit more general I would like to use a custom define for eDMA driver Destination address expression:

Is it somehow possible to include e.g. #define SPI_INPUT_CHAIN_LENGTH (4) for use in peripherals.c without modifying the file directly?

I think if I manually include this in peripherals.c next time I update the code it will be overwritten.

If nothing else is possible it could be included as preprocessor symbol, but I don't really like this solution because for every EWARM project I would have to define this in the project options.

Kind regards,

Stefan

[marek_neuzil]

Hi Stefan,

The definition of the macro is not supported in the eDMA now. But your use case can be supported in a new version of MCUXpresso Config Tools. I will create a new feature request for your issue. 

In the meantime you can use another pointer into the array you want to use, for example:

AT_NONCACHEABLE_SECTION_INIT(uint32_t *bSpiInputShiftRegisterData_DmaPtr)  = &bSpiInputShiftRegisterData[SPI_INPUT_CHAIN_LENGTH-1];

Thus you can use the bSpiInputShiftRegisterData_DmaPtr pointer in the eDMA component as it is currently supported.

Best Regards,

Marek Neuzil

[mitterha]

Hi MarekNeuzil‌,

please add the following to the feature request:

If it is possible to use own defines for address expressions it also makes sense to be able to use the same define in other fields e.g. "Last address adjustment" in TCD configurations.

Kind regards,

Stefan

[mitterha]

Hello Marek,

thank you for your answer. If I try to use your suggestion (the array is a uint8_t array so there needs to be a cast or change the type of pointer to uint8_t*) IAR compiler shows the error Pe028: expression must have a constant value for the code line

.destAddr = (uint32_t) bSpiInputShiftRegisterData_DmaPtr,

 in peripherals.c

Kind regards,

Stefan

[marek_neuzil]

Hello Stefan,

I am sorry I don't know the implementation of the buffer in your code and the eDMA mode you are using. I have created an IAR project (based on the original "edma memory to memory" SDK project) and I have used the Non-transaction mode (TCD structures). See the attached archive.

There are used the following definitions of the buffer to demonstrate the use case you need to use (see details in the attached project):

AT_NONCACHEABLE_SECTION_INIT(uint32_t srcBuff[BUFF_LENGTH*2]) = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};

AT_NONCACHEABLE_SECTION_INIT(uint32_t *srcAddr) = &srcBuff[BUFF_LENGTH];

(there is not any warning and error reported by the compiler).

In case you are not able to provide a constant pointer you must assign the address later in your code (and also provide initialization of the eDMA channel - TCD registers, e.g. by using the EDMA_InstallTCD() function).

Best Regards,

Marek Neuzil

[mitterha]

Hello Marek,

thank you for providing the example, I was defining an external pointer in MCUXpresso instead of an array. I still have a problem with the code because the address which is written as destination address in the dma config structure is not correct.

The generated code in peripherals.c is

/* Destination address extern definition */
extern uint8_t lastInputShiftRegisterData[];
edma_transfer_config_t DMA0_LPSPI_RECEIVE_1BYTE_config = {
  .srcAddr = (uint32_t) (&LPSPI1->RDR),
  .destAddr = (uint32_t) &lastInputShiftRegisterData[0],
  .srcTransferSize = kEDMA_TransferSize1Bytes,
  .destTransferSize = kEDMA_TransferSize1Bytes,
  .srcOffset = (int16_t) 0,
  .destOffset = (int16_t) 0,
  .minorLoopBytes = 1U,
  .majorLoopCounts = 1U,
};

this results in destAddr = 0x20000074 which is not the correct address.

The following code line in main 

volatile uint32_t address = (uint32_t) &lastInputShiftRegisterData[0];

which is the same as used in peripherals.c results in address = 0x20000070 which is the correct address of the last array entry. The arrays are of type uint8_t and the pointer is pointing to the 5th element in the array.

I can not verify if the same problem is true for your provided example because we do not have a RT1060.

We decided to use our own header file for our defines and include this file in peripherals.c (saves a little bit of memory because no pointers are needed). In case we have to modify some settings with mcuxpresso config tools we just have to add the include to peripherals.c again after updating the source code.

Thank you very much for your help!

Stefan