This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

McASP+UART Release App conflict with Neon and VFP coprocessors

Hello;

In our design we want to inferface an ADC with my Beaglebone and then send the information through UART. We are using McASP (McASP0) configured in interrupt mode (no DMA), where after every adquisition of McASP data, data is processed and once in a few adquisitions, data is sent through UART1. We are using Starterware.

We want to acquire data and process it it a high frequency, and here is where our problem appears. As the data processing time is quite high (around 2.5 useconds), we have activated the Neon and VFP coprocessors (both in our projects and in the system, utils, platform and devices projects). In a simple desing where only the data processing functions are included, we can check easily (with some GPIO toggle) that the data processing time lasts around 300 nseconds. However, if we activate the Neon and VFP coprocessors in the McASP release app, the McASP does not happens and the ISR does not activate.

Is there any conflict (Starterware, processors, ARM...) between the Neon and VFP coprocessors and the McASP? Where is the error? Is not possible to combine Neon and VFP coprocessors with McASP?


Thanks a lot.

  • Hi Pedro,

    Can you clarify on a few things like what is the version of StarterWare you are using?  Have you taken care of saving and restoring the VFP/Neon register context in an Interrupt Handler?

    In StarterWare 02.00.01.01 exceptionhandler implementation we take care to save and restore the Neon/VFP context Please refer to the system_config/armv7a/am335x/gcc/exceptionhandler.S file where the code to save/restore the additional registers is implemented.

    Can you include this changes and check the McASP application.

    Regards

    Anant