CyU3PU***RegisterSetupCallback的回调函数是否存在约束

嗨，丹尼斯姆
一般建议不要在回调函数中设置任何调试语句。这是因为有可能非常频繁地调用回调，并且会导致设备挂起。
此外，如果您正在讨论在DMA回调函数中执行操作，那么您应该首先使用GETFuffor。
破布



     以下为原文
  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

我移动了供应商的命令处理使用事件系统，并在主线程上处理命令。即使没有调试启用，我们有时也有固件挂起。我想，正如你所说的，DMA回调也可能是个问题。在API指南中，它谈到需要足够快来处理那些数据。我不确定应该如何处理那些需要慢慢写入的数据。例如，假设我有一段时间写或读，有没有一个最好的练习这种类型的情况？



     以下为原文
   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?

HI DeNISJM，当然，缓慢的回调只会影响性能，并且不应该导致软件挂起。顺便说一下，CYU3pDebug打印的错误代码之一是CyuU3PyErrRoValudioCalor（从中断调用），因此我相信它检查上下文本身，因此即使从中断上下文调用它也不应该引起挂起。当然，用CYU3pStudiAdDebug（）自己检查上下文也不会有坏处。SW悬挂的一个可能的原因可能是截断的图像部分。我自己已经打过好几次了。ELF2IMG转换器将所有4字节的多个部分截断为4字节多个。验证所有的程序段是4字节多个，或者自己修复ELF2IMG（延长部分而不是截断）。EF2IMG错误列出在线程HTTP://wwwyCysP.COM/？APP =论坛和ID = 167和RID＝78171 BR，
卡列夫



     以下为原文
  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

实际上，我在日志语句的开头使用了Cyu3pStudiAddiy来确定几个函数来自哪个上下文。只有两个是供应商命令上下文和应用程序线程。看起来，DMA回调与应用线程处于同一线程上。如果我在一个无效的地方使用了一个调试语句，我想我还不知道，因为我想如果它返回无效的调用方，它实际上不会打印。不过我不认为这是个问题。
我会检查更多的ELF2IMG错误/问题，看看是否有什么变化。



     以下为原文
   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.

我在第195行向EFF2IMG添加了调试语句。我的固件映像确实击中了那个代码并截断了
到：
Fixsz＝Fielz。
您在另一个线程中提到，您可以以某种方式验证您的固件是所有4字节对齐的部分，但我还没有弄清楚如何做到这一点。我不确定这是不是引起了我的问题。当我添加打印语句进行调试时，我仍然有更多的挂起，但是我没有看到是否启用了打印，以及图像分割是否都是4字节对齐。



     以下为原文
   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.

嗨，丹尼斯姆，
检查地图文件-所有的部分和它们的长度列出在那里。我的问题是节长不是4字节多（它被正确对齐到4字节边界）。由于截断，该段的最后2个字节没有从ELF复制到IMG。
在线程HTTP://CyPress？COM/中列出的ELF2IMG源代码行编号？APP=论坛和ID；ID＝167和；RID＝78171与在同一线程中引用的ELF2IMG.C有关（HTTPS://www. DROPBOX.COM/S/L3FSY3KUBBW14X/BooToLoSerixEntudio.Zip）。
截断是用指令执行的：
MEMSZ＝PROFRDR & GT；MESIZESS／4；
Fielz＝PROFRDR & GT；文件化/ 4；
要纠正这一点，正确的做法是：
MeMSZ＝（PRODHDR＆GT；MESIGHESS＋3）/ 4；
Fielz＝（PRODHDR & GT；文件化+ 3）/ 4；
可以看出，ELF文件在末尾没有额外的数据读取，因此，也可以修改从文件中读取的内容：
/*StudialSyrd＝FRAAD（缓冲器，4，RealLin，FPELF）；*/
FalalyRD＝（FRAAD（缓冲器，1，RealLee * 4，FPELF）+ 3）/4；
Br
卡列夫



     以下为原文
  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

谢谢。
我实际上跟踪了可能截断图像的线条，我只是没有找到正确补偿的最佳地方。同时，我只添加了一个警告，重复检查大小是4的直接倍数，因此没有被截断。我已经证实，至少暂时，我没有碰到这个bug。
我仍然看到的是，在特定的地方添加调试打印将导致固件挂起。我排除了EP0供应商命令回调和DMA回调。之后，我切换到处理应用程序线程上的供应商命令，并使用来自StupUCB的事件。但我认为这不是个问题。
因此，基本的程序结构是：
塞特普布
{
…事件后…
}
附加条目
{
…处理事件…
调用读写函数（）；
}
Read StUpUpLoad（）{
设置DMA通道。W/回调
如果我在这里添加一个打印语句，它可能会挂起固件。
调用初始读取FUNC到质素缓冲器。
}
回调{
我可以在这里添加所有的打印语句
如果未传递所有字节{
调用函数
}
}
RealFunc（）{
如果我在这里添加一个打印语句，它会挂起来，
但是如果我有条件的打印语句，所以它没有出现在第一次读，我认为它是罚款。
填充EP缓冲器
}
不管怎样，我似乎有一个比打印语句更特殊的问题，但是打印语句会使问题变得更严重，并且容易复制。我看到固件挂起调试完全禁用有时，但似乎更难得。我认为这可能源于同一个核心问题。看来我应该能够在任何这些地方打印出我想要的（或者换句话说，做一些不立即返回的处理）。
谢谢你继续的输入，它帮助我更多地接触这个芯片。



     以下为原文
   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. 

嗨，据我所知，你在呼叫链中更深入，更可能是SW挂起。堆栈溢出是真的吗？我检查了LST文件。大多数固件API线程是用堆栈大小1K（0x400）字节创建的（如果你感兴趣的话，可以搜索一下它的xxeththRead创建）。对于您自己的应用程序线程，您自己指定堆栈大小- CyPress示例指定4K.Br，Kalev



     以下为原文
  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

是的，这个固件是用一个4K（0x1000）堆栈来启动应用程序线程的。我们把它从CyfxBulkPr手册示例开始。有一次，我认为这可能是个问题，但我试着增加线程的大小，得到同样的结果。
这可能是问题的一部分。我使用的是256K部分，而不是像开发板一样的512K。也许我遇到了一个问题，有些东西没有它需要的内存（比如C运行时或其他什么）。



     以下为原文
   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)