• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 232 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

McBSP is sleeping sometimes

James Thorton
Expert 1390 points

EDIT: I have edited the title as we are seeing that the problems seems more related with McBSP than edma, see last post

Hello, I really need the last help to finally boost my project. I am very close to finish it, but need some help from you. What I have is a third party application that is using ACPY3 (which use EDMA), I don't have any access to this code so in this point our hands are tied. I have add to this application my code which needs to serve the McBSP, I have decided to use EDMA to serve McBSP as it is the best (if not the only, due to the features of the project) approach. What I have been experimenting working with it, is that sometimes the reception of McBSP is not working properly. Sometimes and without any apparent reason, the reception fails, it is not related with a code-problem as sometimes work perfect.

I guess the problem is connected with endpoints access, I mean, I think my third party application is using ACPY3 to access same memory space that I am using, so my reception fails as it need to write in a buffer. I am working with dm6437 and I have tried to allocate in internal memory (L1SRAM) and in external (DDR2) with no 100% success in both cases.

Could someone please give some tips about how to solve this problem? I found that there is a RDRATE register to limit the read-accesses to memory, but there is no equivalent for writte-accesses, I think with somethink like this my endpoints will be solve.

 

Thanks in advance and regards

 

 

  • 0
    Expert 1390 points

    dm6437 as slave SPI problem:

    It seems that I am closing to the issue. More data, as I said, I am using dm6437 as slave SPI, and I am founding the next issue in a transmission: see the pics attached.

    I will try to explain my results. Look at the good transmission pic, IN, CLOCK, and ENABLE pins are driven from master. When it is in a disable area IN goes high. This does not happen when I obtain a bad transmission. As you can see IN pin is kept low. You could think that I should maintain IN in high level in order to achieve a good transmission.But if you look, in the first byte both transmissions are the same and IN pin is kept in low in "disable zone", in despite of it, the next byte is well transmitted. So, apparently, to maintain or not the IN pin in high is not causing directly a good or bad transmission. But it seems that always that I achieve a good transmission I obtain this effect, so it has to be some relationship between both facts. Anyway, I could not configure master to keep IN pin in high level (there is no feature to do that in master device).

    I would like to add that this pics shows what I consider a "reception", although could seem a full-duplex operation, you can see that out pin is sending 0xFF (so when OUT is not responding 0xFF it means that no receptions on dm6437 is being done neither) which is "don't care data" for master, i.e., the only who is getting data is the SLAVE (reception for dm6437). And when I refer that it fails, it means that any data is saved in my buffer (dm6437 side).I do not know if that is related with EDMA effects... to remember the things just read the upper post.

     

    Thanks to any advice

     

  • 0 in reply to James Thorton
    Expert 1390 points

    Hello, I have changed the title of the topic as we are seeing that the behaviour that we have is that McBSP is not responding in the "bad reception" graphs, I mean, when this malfunction happen in the DXR is written 0xFF, so it should happen that Out at least shift this value continuosly, although EDMA does not work. So it seems to be an issue more related with McBSP than EDMA, as I said, still in the case of any malfunction, you should expect that at least McBSP would be shifting the content of DXR although it is not updated.

    So, it seems like McBSP goes to sleep on receptions, only sometimes and then wakes up, and works again properly. I don't do anything more than initalization, so it is very weird.

    Edit: by the way, I am using CSL to initialize McBSP. As I have receive suggestions to avoid CSL (I think that is being deprecated) could it be this the main issue? I have used CSL as I have been reading that McBSP driver has no support for SPI configuration