iMX7 external Memory

Technical Support
, , , ,
1

a write to an external memory failed, if there is a word or dword access to a odd address.
Mirosoft recommends an cached memory access .

How can I define the external memory area (0x28000000-2FFFFFFF) as cached memory?
I can not see the OEMAddressTable.

2

Dear @maha
I don’t think that caching this memory would solve the problem. Can you please provide more information where the error happens: Is this part of your code (what statement?), or is it within the ToradexLib 2.1, that you mention in your environment (In which function call?).
Regards, Andy

3

Dear andy,
here a C-Code example for a exception error

WORD *pwRetainArea = (WORD*)Map_MapMemory(0x28000000, 0x200000);
// pwRetainArea points to a even address

unsigned char *pBytePtr = (unsigned char*)pwRetainArea;
++pBytePtr; // odd address
WORD *pWordPtr = (WORD*)pBytePtr;
*pWordPtr = 0xBBBB; // Crash

Regards, maha

4

Changing the AUS bit will not prevent the write to external memory on odd addresses from not failing.

Referring to your code, instead of declaring pBytePtr as a (unsigned char *), you may declare it as a word or dword pointer, and increment it, If you have the AUS set to 0, the address on the memory bus would automatically appear shifted and you would only see sequential addresses on the bus even when your pointer in the code is increment by 4, when you do ptr++.

below are the steps, that might be of help to you

  1. Set AUS to 0.
  2. Create a word pointer, (WORD *)pWordPtr = NULL;
  3. Initialize pWordPtr to the mapped physical memory address.
  4. Read/Write to *pWordPtr.
  5. Increment pWordPtr, pWordPtr++. (pWordPtr would increment by 4)
  6. But since you have the AUS set to 0 you would see shifted address (Right shifted by 2 bits) on the External Memory Bus.
5

Dear kapeed,
change of AUS Bit unfortunately have no effect.

Regards, maha

6

Changing AUS will not prevent the external memory access from failing for the case of word access at non-aligned word addresses.

Setting AUS to 0, will make the aligned word access appear sequential on the external memory bus. If this is what you want to achieve.

From your code I can see what is going wrong, the pBytePtr is a pointer to byte, you are incrementing it and assigning it to a word type pointer and then performing a write access to the pointer. When the pBytePtr is non-word aligned your code is crashing. Because this is a logical error.

Instead what you can do is:

  • Set the AUS bit to 0, to see shifted address on the external memory bus (shifted right by 2 bits, for a External memory that has DSZ set to word).
  • Create the pWord pointer as you are doing it now.
  • Initialize the pWordPtr to the mapped (physical to virtual) base external memory address zone.
  • Perform read and write at pWordPtr.
  • Increment pWordPtr, pWordPtr++. The pointer would increment by 4 but on the external memory bus you would see sequentially incremental addresses, because of the AUS set to 0
7

The memory is byte addressable so addresses for accessing dword(32 bit) or word(32 bit) data in the memory should at the least be even and aligned according (divisible by 4).

If your external memory expects sequential addresses for word/dword accesses(0,1,2,3 … ) maybe using the AUS (Address Unshifted) in the WEIM Configuration registers be of some help.

8

Dear @maha

Before searching a way how to enable unaligned accesses, you must validate the basic requirements:

  1. Is your hardware capable of processing unaligned accesses? Please provide the detail information about all signals of the EIM bus and how they are connected to your external device.
  2. If the hardware allows unaligned accesses, we need to verify that this is supported in the EIM configuration registers.

There would be even an option to enable unaligned accesses on CPU level (within an ARM coprocessor register). However, this is a deep system change which I recommend only to do as a last resort.

Before this, the question is whether unaligned accesses are required at all, or whether they could be avoided by small modifications of the application source code.

Regards, Andy

9

Hi Andy,
I sent you the schematics per email and here the WEIM-Register settings.

pWEIM->CS0GCR1: 00610089
pWEIM->CS0GCR2: 00001002
pWEIM->CS0WR1:  1f6fffd3
IOMUXC_GPR1:    4f402007

The C-Code is only an example to show the reason for the exception.
But to problem is a SPS-Software running on our device which generate code, I have no bearing on and there are access of word variables at odd addresses.
We can read/write char-Variables on every addresses even and odd addresses.
We can read/write word -variables on even addresses.
In the microsoft article looks like MMU and cached memory could resolve this problem.

Best regards,
maha

10

Dear @maha,

Did you upload files in https://share.toradex.com/?

We can’t download the files without the link.

Could you please upload files again on https://share.toradex.com/ and post the link here.

Thank you

11

Dear raja,
the upload link is https://share.toradex.com/ci7t5zbd1cg46d3.
I sent you the link 16.04.18 per email.

Best regards
maha

12

Dear @maha,

Sorry to bother you again. The link is not valid, I am not able to download the file. Could you please select 3 months or 1-year validity while uploading the file on https://share.toradex.com/. Also, I didn’t find your support request on 16- Apr - 2018.

Thank you.

13

Dear raja.tx,
I tried the upload agian, the link is https://share.toradex.com/vcfkm4bzd2soog5.
Sorry for my mistake with validity.

Best regards
maha

14

Dear @maha,

Sorry, This time also the link is not valid. Could you please use Attachment feature to share the file with us. If there are no executable files then you can write a mail to support@toradex.com.

Thank you for your patience.

931-attachment.jpg

15

Hi Andy,

Thank you for the email and support.
I will send you the schematics and the WEIM-Register settings.

pWEIM->CS0GCR1: 00610089 
pWEIM->CS0GCR2: 00001002 
pWEIM->CS0WR1:  1f6fffd3 
IOMUXC_GPR1:       4f402007

The C-Code is only an example to show the reason for the exception.

But to problem is a SPS-Software running on our device which generate code, I have no bearing on and there are access of word variables at odd addresses.

We can read/write char-Variables on every addresses even and odd addresses.
We can read/write word -variables on even addresses.

In the microsoft article looks like MMU and cached memory could resolve this problem.

Best regards

16

Hi raja,

the link you request is:

https://share.toradex.com/s43c45rc39drys1

thank you for the support.

Best regards,

17

Hi Andy,

are the information I sent last week helpful for you?
Could you check the weim register values and the schematic or the Microsoft advice?

Best regards
Manfred Hauser

18

Dear @maha

First, can you please confirm that bytewise access (through char* pointers) are working on odd and even addresses.

  • If this works, the following could be a solution:
    Disable the strict alignment check in the ARM coprocessor register, then the CPU core will allow unaligned accesses.
    The CoprocLib Demo (part of the Toradex CE Library package) contains such a function. Please note, that every core contains its own coprocessor. On the Colibri iMX7D, you need to execute the code on each of the two cores to fully allow unaligned accesses.
  • The solution of defining a EIM memory range as cached could work, too. But it requires you to have the application under control in order to be able to flush the cache whenever required.Otherwise you cannot be sure whether data has actually been written to your external SRAM, or whether it is still in cache only.

Regards, Andy