Hi, TI expert
We used 12 DMA channels in mcu3-0, and after modifying "rm cfg. c" to allocate DMA resources, the 12 channel DMAs worked normally. However, when using timerP at the same time in mcu3-0, many times the DMAs caught missing or unable to catch data. If timerP is not applicable, this situation will not exist.
Version information: sdk8.02 Linux&rtos.
Please assist in the investigation, thank you~!
Hi，Erick & Brijesh
May I ask how the resources of dmtimer are allocated between different CPU cores?
Is the dmtimer corresponding to the timer shown in the following two figures_ What about IO association?
If we use dmtimer2 as a regular timer and do not use dmtimer signal; How should the timer be configured when dmtimer2 corresponds to "TIMER_IO2" (AD23) used as a regular gpio?
Looking forward to the prompt response from the two TI experts.
Regards.
jiawentao
Hi, Brijesh
But i thought this is DMA issue, not the timer issue, since you confirmed that waveforms to USS are sent out correctly even when inference application is started and its only DMA getting delayed, isn't it?
Some time ago, I observed the waveforms of the sent waves and echoes through the oscilloscope on the bench, and I did see that the echoes were correct.
But I just did further tests on the real car, and I calculated the time difference between entering the Timer ISR 3 times before the frame drop occurred (because it is necessary to enter the Timer ISR 3 times to pull down the GPIO 100us to make the ultrasonic module emit waves, the first two times to enter the ISR to pull down the GPIO, and the third time to enter the ISR to pull up the GPIO);
I found that after launching the image inference app, the time difference of the Timer fluctuated greatly around 100us every time the frame was dropped, and the time difference between 30us and 180us was fluctuating. That's true around 100us, but it can be small or large after launching the inference app
volatile int cnt_front = 0;
volatile uint64_t emit_ts_rec[3] = {0};
void uss_front_timer_callback(){
uint8_t gpio_send;
switch(emit_status){
case EMIT_READY:
cnt_front ++;
if(cnt_front < 3){
for(int i = 0; i < 12; i++){
uint8_t gpio_send = snrGetGpioIdx(i/4, i%4, GPIO_OUT);
GPIOPinWrite_v0(CSL_GPIO0_BASE , gpio_send, GPIO_PIN_HIGH);
}
emit_ts_rec[cnt_front] = appLogGetTimeInUsec();
}else{
for(int i = 0; i < 12; i++){
uint8_t gpio_send = snrGetGpioIdx(i/4, i%4, GPIO_OUT);
GPIOPinWrite_v0(CSL_GPIO0_BASE , gpio_send, GPIO_PIN_LOW);
}
emit_status = ECHO_READY;
cnt_front = 0;
emit_ts_rec[cnt_front] = appLogGetTimeInUsec();
}
break;
case ECHO_READY:
TimerP_stop(FrontUssTimerhandle);
break;
default:
break;
}
}
//This is the print code for counting lost frame data after reading dma buf in the while loop
cnt_data_sum ++;
if(count<(STATUS_LEN+2)*2 || count%2) //bad signal
{
cnt_data_lost ++;
printf("[%d:%d] lost=%lld sum=%lld count=%d timer_delay=%lld\n",sd, chl, cnt_data_lost, cnt_data_sum, count, emit_ts_rec[0] - emit_ts_rec[1]);
}else{
printf("[%d:%d] count=%d timer_delay=%lld\n",sd, chl, count, emit_ts_rec[0] - emit_ts_rec[1]);
}
Probably lets first try by making fps to half and see if it improves
I also reduced the frame rate of graphics inference applications, such as from 30ms to 60ms, then to 100ms, and then to 1s, and indeed the frame loss rate was significantly reduced, at 1s/frame, the frame loss rate in 5 minutes was less than one thousandth.
At present, it seems that it is not DMA capture that drops frames, is it that the Timer interruption is affected by the image inference application? Is there a way to ensure the real-time performance of the Timer ISR if the ISR is too early or too late?
Regards,
jialin xie
