AM2434: GPMC Burst Mode Word Ordering Issue (16‑bit Bus to FPGA, Sync NOR‑like)

Hi Ariel,

Thank you for your query !

Please allow me some time to internally discuss with the topic owner.

I may need to reach out to our GPMC HW and SW experts.

I hope I can get back to you with a response by Monday (March-30-2026) COB.

We appreciate your patience !

Best Regards 

Anastas Yordanov

Hello Ariel,

Did you try with memcpy like Anil is suggesting in this e2e thread?

AM6442: Question on GPMC Burst Mode Commands/Software Development

Resolved

Part Number: AM6442 Hi, I have received a couple general questions from a customer regarding writing code for their AM6442's GPMC peripheral. According to them, they are currently using GPMC in burst…

By Michael V 11 months ago in Processors > Processors forum

3 replies

Latest by Swargam Anil 11 months ago

Also, is it possible for your setup to read back the written  to FPGA data, just for the test? I can see you are not setting the Read Multiple bit, you may need to set it to 1 so we make sure reads and writes are in the same mode:

I've reached out to GPMC expert, I don't know GPMC internal function and software that good.

Thanks,

Stan

Hi Stan,

Thank you much for jumping in !

Hello Ariel,

I would like to apologize for the big time gap in my response.

In order to be able to isolate any possible root cause from software side, can you specify:

the type (Linux / MCU PLUS) and version of the AM243x SDK you are using ?

Thanks

Best Regards

Anastas Yordanov

Hi Stan and Anastas,

When I read the register after writing, I get the reversed order (which matches the behavior observed in this issue).
The memcpy operation generates the same data order.

I also tried configuring the read operation as burst, but this did not resolve the ordering problem.

Environment:

• SDK: ind_comms_sdk_am243x_11_00_00_13
• SysConfig: sysconfig_1.25.0
• OS: FreeRTOS
• Active Cores: R5F_0_0, R5F_0_1

I do not think this is a software issue, because changing the configuration changes the behavior.

If I change WRACCESSTIME to 2, the configuration becomes:

With this configuration:

• The data order becomes correct
• However, I get an extra clock cycle, which also generates a write to an address that I did not request (see picture below)
  

Additionally, this configuration fixes the ADVN operation.
In the original configuration, this line does not work properly.

I can work with the extra clock cycle if the GPMC requires it. However, in that case, I need WEN or CSN to go to '1' during this cycle, or BEN to go to "11", in order to avoid generating an extra write.

My main goal is to achieve:

• 1 clock cycle for the address
• 1 clock cycle for each data write

Best Regards

Ariel Gershengold

Hi Ariel,

Ariel Gershengold said:

My main goal is to achieve:

• 1 clock cycle for the address
• 1 clock cycle for each data write

Is it an option for you to divide down the external clock? This way the controller will have more time to perform internal operations as it still being clocked at internal frequency

:

Hi Stanislav,
No, we need to work at 100 MHz; otherwise, we will have problems with the time required to transfer the data.

If we divide the time by 2, it will be the same as working at 100 MHz without burst.

B.R.
Ariel Gershengold

Ariel Gershengold said:

I can work with the extra clock cycle if the GPMC requires it. However, in that case, I need WEN or CSN to go to '1' during this cycle, or BEN to go to "11", in order to avoid generating an extra write.

Actually isn't it fixing the double writing at the end of burst? Shortening WEN, CSN times? Did you already try it? Looks to me it would also meet the 1-clock criteria?

Regards,

Stan

No you can see in the record the BEn is "00" in the double writing. I try to change the WEn and CSn times but I did not see the expected effect. 
B.R.
Ariel

Hello Ariel

Thank you for the inputs.

The expert is out of office on Monday.
Please expect delay in response.

Regards,

Sreenivasa