AM62A7-Q1: ECAP Module Buffer Deep

Hello,

I have assigned your thread. Please expect delays due to the holidays. Feel free to ping the thread if you do not have a response within the first week of January.

Regards,

Nick

Hello Kevin

Thank you for the query.

Would you mind sharing the application use case including the ECAP input.

Based on your inputs i need to check internally.

Regards,

Sreenivasa

Hi Sreenivasa,

Thanks for your reply!

There is a USS capture user guide shown below.

https://www.ti.com.cn/cn/lit/an/zhcab72/zhcab72.pdf

Because it is in Chinese version, I translated the ECAP part using English in the below file.

USS_Capture.docx

Basically now in the Automotive market, there are more customers showing interest in our AM62A to implement 1V1R12USS application. They need 12 channels to capture 12 channel USS data. As we know that using GPIO without DMA needs more CPU loading than the ECAP module. In AM62A we just support 10USS channels that could use GPIO + DMA method shown in the below thread.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1299971/am62a7-am62a1-mcu-use-gpio-to-trig-dma/4947573?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1306484/am62a7-q1-gpio-udma-for-12-uss-capture

Then the left 2 USS channels need to use ECAP module to achieve that.

Kind Regards,

Kevin

Hello Kevin,

Thank you for the inputs.

Let me review the inputs. I will have to reach out to the experts internally.

Please expect delay in response since many of the Dallas team members are on vacation this week.

Regards,

Sreenivasa

Hi Sreenivasa,

Any update we could have so far?

Thanks,

Kevin

Hello Kevin,

Thank you for checking.

I checked with the design team and looks like there is no provision to be able to do what you are asking.

I am also reaching out to the IP team to check if there are any suggestions.

I will update when i have some inputs.

Regards,

Sreenivasa

Hi Sreenivasa,

Thanks for your reply.

However, I am not understand why we have 3 ECAP modules but could not even do 2 channel USS data capture. If the reason is that there is no DMA resources on ECAP module, that is fine because we do not need DMA resource on ECAP module as ECAP consumes much less CPU resources than a general GPIO interrupt.

Apart from the ECAP module, we also think about another alternative way. As we know we have 10 DMA channel resources, if we put the 12 channel USS within a single GPIO bank (1 GPIO bank contains 16 GPIO), then we only need 1 DMA channel on this GPIO bank to complete this task.

I think both of the following two methods are supposed to work for 12 channel USS data capture theoretically.

1: 10 single GPIO + 10 DMA with 2 ECAP modules

2: 1 GPIO bank + 1 DMA

Could you help to check the two methods please?

Thanks a lot!

Kevin

Hello Kevin, 

Thank you.

Kevin Peng said:

However, I am not understand why we have 3 ECAP modules but could not even do 2 channel USS data capture.

Not sure i understand your thoughts. The initial question was ob buffering the ECAP information.

Kevin Peng said:

2: 1 GPIO bank + 1 DMA

Do you have some implementation thoughts that you could share for the team to review.

I am assigning the thread to the software expert supporting DMA.

Regards,

Sreenivasa

Hi Sreenivasa,

Thanks for your reply.

For the original question about the ECAP depth, I saw in our TRM we mentioned that we have interrupt capability of any of the 4 events in each ECAP module, so there should not be any problem.

For the 1 GPIO + 1 DMA, my thought is that, because our GPIO bank contains 16 GPIO, then we could use 12 GPIO within the GPIO bank to connect 12 USS channel. Then on the DMA side, we just use 1 DMA channel to control the GPIO bank, then by doing so, 1 DMA channel with 1 GPIO bank should be enough to do 12 USS channel capture.

Kind Regards,

Kevin

Hello Kevin ,

Kevin Peng said:

For the 1 GPIO + 1 DMA, my thought is that, because our GPIO bank contains 16 GPIO, then we could use 12 GPIO within the GPIO bank to connect 12 USS channel. Then on the DMA side, we just use 1 DMA channel to control the GPIO bank, then by doing so, 1 DMA channel with 1 GPIO bank should be enough to do 12 USS channel capture

Based on the above statement, I have some analysis points.

case 1:

12 radars detected the objects at the same time and generated responses at the same time.

Now, from the 12 USS sensors, a start and stop pulse is triggered on the single GPIO pin. Based on this pin pulse, we can calculate the time, and there are no issues.

case 2:

12 radars detected the objects at the same time and generated responses at the different time slots (the delay would be n seconds for each sensor output).

Now, from the 12 USS sensors, a start and stop pulse is triggered on the single GPIO pin. Let's say the response is generated by two sensors, which generate the GPIO interrupt and store the time values based on that pulse. The other sensor generates a response after some nsec; we store this time based on the GPIO pulse. And there is no issue.

Now, how can we detect which sensor is generating a pulse? Since we are storing time based on the one GPIO interrupt for all 12 USS sensors,.

If you want to know which sensor is triggered, you need to poll the GPIO pin status in the DMA interrupt for every sensor, and we are avoiding this software overhead in the application. That's why we are proposing AUTO trigger DMA based on the individual GPIO pins and not on the single GPIO pin for USS sensors Applications .

If you are ok with polling the GPIO status for each DMA interrupt and time is not critical, you can use this method; otherwise, you can use the DMA auto-trigger method based on the individual GPIO pins. In this case, you don't need to add any software overhead, and all the processing is done by UDMA HW.

So, your proposed method seems invalid for your use case. And let me know your thoughts.

Regards,

S.Anil.