Are there constraints on callback function for CyU3PUsbRegisterSetupCallback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 I'm curious if there are stack and/or timing constraints on the callback for receiving vendor commands.  I added some debug statements and a number of function calls to a specific vendor command and upon invoking that command the firmware stops responding.  Remove the debugging and it functions normally.  I'm curious if the correct way is to use event notification and process the request on the application thread instead?  I haven't found a good reason why the debugging would cause firmware to stop responding.  Any thoughts?

0 Likes
9 Replies
RaN_283461
Level 2
Level 2

hi  dennisjm

   

It is generally adviced not to put any debug statements in the callback function. This is because there is a possibility that the callback could be called very frequently and will cause the device to hang.

   

Also if you are talking about doing operations in dma callback function then you should use the getbuffer first.

   

Rags

0 Likes
Anonymous
Not applicable

 I moved the vendor command handling to use the event system and process the command on the main thread.  Even without debugging enabled though, we sometimes have the firmware hang.  I think like you said the DMA callbacks might be a problem too.  In the api guide it talks about needing to be fast enough to handle the data in those.  I'm not sure exactly how one should handle data that needs written slowly then.  For instance, suppose I have a periferal that takes a while to write or read, Is there a best practise for this type of situation?

0 Likes
Anonymous
Not applicable

Hi dennisjm,

Sure, slow callbacks should affect performance only and they should not cause software hanging.

BTW, one of the CyU3PDebugPrint returned error codes is CY_U3P_ERROR_INVALID_CALLER (called from an interrupt), so I believe it checks context itself and therefore even calling it from interrupt context should not cause hanging. Of course, it does not hurt to check context with CyU3PThreadIdentify() yourself as well.

One possible reason for SW hanging could be a truncated image section. I myself have hit this issue several times. Elf2img converter truncates all not 4-byte multiple sections to 4-byte multiple. Verify that all your program sections are 4-byte multiple, or, fix elf2img yourself (lengthen the section instead of truncating). Ef2img bugs are listed in thread http://www.cypress.com/?app=forum&id=167&rID=78171

br,

   

kalev

0 Likes
Anonymous
Not applicable

 I've actually used CyU3PThreadIdentify at the beginning of the log statements to figure out which context a few functions were coming from already.  The only two were the vendor command context and the application thread.  It looked like the dma callbacks were on the same thread as the application thread.  I guess I wouldn't know yet if I used a debug statement in an invalid place because I suppose if it returned invalid caller it wouldn't actually print.  I don't think that is the issue though.

   

I'll check into the elf2img bugs/issues more and see if that turns anything up.

0 Likes
Anonymous
Not applicable

 I added a debug statement to elf2img at lines 195.  My firmware images does hit that code and truncate the 

   

to:

   

validSz=fileSz.

   

You mentioned in the other thread you can somehow verify that your firmware is all 4 byte aligned sections but I haven't figured out how to do that.  I'm not sure this is causing me an issue or not.  I do still have hangs more often when I add printing statements to debug but I haven't seen a difference whether or not I have printing enabled and whether or not the image sectiosn are all 4 byte aligned.

0 Likes
Anonymous
Not applicable

Hi  dennisjm,

   

Check map file - all sections and their lengths are listed there. My problem was that section length was not 4-byte multiple (it was aligned correctly to 4-byte boundary). Due to truncating, last 2 bytes of the section were not copied from elf to img. 

   

Elf2img source line numbers listed in thread http://www.cypress.com/?app=forum&id=167&rID=78171 are relevant to elf2img.c referred in same thread  ( https://www.dropbox.com/s/l3fsy3akkubw14x/bootloader_embedding.zip ).

   

Truncating is performed with instructions:

   

memSz = progHdr->memsize / 4;

   

fileSz = progHdr->filesize / 4;

   

To fix this, correct will be:

   

memSz = (progHdr->memsize+3) / 4;

   

fileSz = (progHdr->filesize+3) / 4; 

   

It can happen that elf  file has no extra data at the end to read, therefore, modify reading from file as well:

   

 /*actual_rd = fread (&buffer,4, readlen, fpElf); */

   

 actual_rd = (fread (&buffer,1, readlen*4, fpElf)+3)/4; 

   

br,

   

kalev

0 Likes
Anonymous
Not applicable

 Thanks. 

   

I did actually track down the lines that potentially truncated the image, I just hadn't figured out the best places to compensate correctly.  In the mean time, I just added a warning to double check that the sizes were directly multiples of 4 and thus weren't being truncated.  I've verified that at least for the time being, I'm not running into this bug.

   

What I am still seeing though, is adding a debug print in a specifc place will cause the firmware to hang.  I've ruled out the ep0 vendor command callback and also the dma callback.  I've since switched to handling the vendor commands on the app thread and using an event from the SetupCB.  I don't think that was ever a problem though.

   

So basic program structure is this:

   

SetupCB 

   

{

   

.. post event ..

   

}

   

AppThreadEntry 

   

{

   

.. handle event..

   

callreadsetupfunc();

   

}

   


   

readsetupfunc() {

   

setup dma channel. w/ callback

   

// if I add a print statement here it'll likely hang the firmware

   

call initial read func to prime buffer.

   

}

   

callback {

   

// I can add all the print statements here I want

   

if not transfered all the bytes {

   

 callreadfunc

   

}

   

}

   

readfunc ( ) {

   

// if I add a print statement here, it'll hang, 

   

// but if I made the print statement conditional so it didn't happen on the first read I think it's fine

   

 fill ep buffer

   

}

   

Anyway, it seems that I have a more special problem than just the print statements but that somehow e the print statement exacerbates the problem and makes it easy to reproduce.  I've seen the firmware hang with debugging completely disabled on occasion but it seems much more rare.  I think it might stem from the same core problem though.  It seems I ought to be able to print in any of these places as much as I want (or in other words, do some amount of processing that doesn't return immediately.)

   

Thanks for your continued input, it's helping me get my hands around this chip a lot more. 

0 Likes
Anonymous
Not applicable

Hi,

As I understand, more deep you are in calls chain, more probably the SW hangs. Stack overflow indeed?

I examined .lst file. Most firmware API threads are created with stack size 1K (0x400) bytes (search for _txe_thread_create if you are interested). For your own application thread(s) you specify stack size yourself - Cypress examples specify 4K.

br,
kalev

0 Likes
Anonymous
Not applicable

 Yes, this firmware was started with a 4k (0x1000) stack for the application thread.  We based it off of the cyfxbulklpmanual example to start with.  At one point I thought that perhaps that was an issue but I tried increasing the thread size and got the same result.

   

It may be an issue with the part.  I'm using the 256k part instead of the 512k like the dev board.  Perhaps I'm running into an issue where something doesn't have as much memory as it needs (like the c runtime or something)

0 Likes