完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
我开始了一个新的线程,因为它使它更容易遵循。我相信代码是和谐2.04。至少当固件运行好一段时间时,它看起来可能是突然出乎意料的产品:1)SypRealSubExpRyLeR2(Simple),SysHelrOrthRebug TCP/IP堆栈:堆删除失败!SysHyrRoRyTrror TCP/IP堆栈:堆创建失败,类型:1SysSyrRoRyTrror TCP/IP堆栈:初始化失败1 -中止!之后,以太网变得不可访问,并且电缆必须被拔掉并被复制以恢复。对于一般的例外,我有用于TBL再填充的SENDATA总线错误加载/获取地址错误,ECP地址通常位于这个函数中:一个总线,地址是iMaMtxPcTeCKAcKeldFor()。我已经看了好几天,但是除了它在项目代码和ReunIalaleDead中有时被取消初始化之外,还没有结论它发生的原因。但是仅仅做了100次,BOT就产生了问题。在问题发生前从2小时到48小时。如果有人对可能的原因有任何想法,或者我能尝试什么,请告诉我。
以上来自于百度翻译 以下为原文 I am starting a new thread for this as it makes it easier to follow. I believe the code is HARMony 2.04. At least it appears that way Device PIC32MZ2048EFG100 When the firmware runs for a good while, it may suddenly out of the blue produce: 1) _general_exception_handler 2) _simple_tlb_refill_exception_handler or: SYS_ERROR_ERROR TCP/IP Stack: Heap Delete fail! SYS_ERROR_ERROR TCP/IP Stack: Heap creation failed, type: 1 SYS_ERROR_ERROR TCP/IP Stack: Initialization failed 1 - Aborting! after which the Ethernet becomes unreachable and the cable must be unplugged and replugged to recover. For the _general_exception_handler I have seen data bus error load/fetch address error For TBL refill, the ECP address usually sits in this function: _EnetPoolFreeDcptList() Disassembly of section .text._EnetPoolFreeDcptList: 9d08bc08 <_EnetPoolFreeDcptList>: 9d08bc08: 27bdffe0 addiu sp,sp,-32 9d08bc0c: afbf001c sw ra,28(sp) 9d08bc10: afb20018 sw s2,24(sp) 9d08bc14: afb10014 sw s1,20(sp) 9d08bc18: afb00010 sw s0,16(sp) 9d08bc1c: 00808021 move s0,a0 9d08bc20: 00a08821 move s1,a1 9d08bc24: 00c09021 move s2,a2 9d08bc28 <.LBB347>: 9d08bc28: 8e040008 lw a0,8(s0) 9d08bc2c <.LVL19>: 9d08bc2c: 8e02000c lw v0,12(s0) ///////////////////////////////////////////////// ECP address = 9d08bc30 for tbl_refill //////////////////////////////////////////////// 9d08bc30: 54820004 bnel a0,v0,9d08bc44 <.LBB350> 9d08bc34: 8c820000 lw v0,0(a0) 9d08bc38: ae00000c sw zero,12(s0) 9d08bc3c <.LBE347>: 9d08bc3c: 0b422f12 j 9d08bc48 <.LBE350> 9d08bc40: ae000008 sw zero,8(s0) 9d08bc44 <.LBB350>: 9d08bc44: ae020008 sw v0,8(s0) 9d08bc48 <.LBE350>: 9d08bc48: 10800007 beqz a0,9d08bc68 <.LVL21> 9d08bc4c: 8fbf001c lw ra,28(sp) 9d08bc50: 5220fff6 beqzl s1,9d08bc2c <.LVL19> 9d08bc54: 8e040008 lw a0,8(s0) 9d08bc58: 0220f809 jalr s1 9d08bc5c: 02402821 move a1,s2 9d08bc60 <.LVL20>: 9d08bc60: 0b422f0b j 9d08bc2c <.LVL19> 9d08bc64: 8e040008 lw a0,8(s0) 9d08bc68 <.LVL21>: 9d08bc68: 8fb20018 lw s2,24(sp) 9d08bc6c <.LVL22>: 9d08bc6c: 8fb10014 lw s1,20(sp) 9d08bc70 <.LVL23>: 9d08bc70: 8fb00010 lw s0,16(sp) 9d08bc74 <.LVL24>: 9d08bc74: 03e00008 jr ra 9d08bc78: 27bd0020 addiu sp,sp,32 For the general exception, data buss, the address is in _MACTxPacketAckCallback() 9d09179c <_MACTxPacketAckCallback>: 9d09179c: 14a00010 bnez a1,9d0917e0 <.LVL361> 9d0917a0: 24050001 li a1,1 9d0917a4: 27bdffe8 addiu sp,sp,-24 9d0917a8: afbf0014 sw ra,20(sp) 9d0917ac: afb00010 sw s0,16(sp) 9d0917b0: 00c08021 move s0,a2 9d0917b4 <.LBB575>: //////////////////////////////////////////// address points here: 9d0917b4 //////////////////////////////////////////// 9d0917b4: 9483fffe lhu v1,-2(a0) 9d0917b8: 8cc20068 lw v0,104(a2) 9d0917bc: 00832023 subu a0,a0,v1 9d0917c0 <.LVL358>: 9d0917c0: 0040f809 jalr v0 9d0917c4: 24061040 li a2,4160 9d0917c8 <.LVL359>: 9d0917c8: 8e02012c lw v0,300(s0) 9d0917cc: 24420001 addiu v0,v0,1 9d0917d0: ae02012c sw v0,300(s0) 9d0917d4 <.LBE575>: 9d0917d4: 8fbf0014 lw ra,20(sp) 9d0917d8: 8fb00010 lw s0,16(sp) 9d0917dc <.LVL360>: 9d0917dc: 27bd0018 addiu sp,sp,24 9d0917e0 <.LVL361>: 9d0917e0: 03e00008 jr ra 9d0917e4: 00000000 nop I have looked at this for several days but have no conclusion as to why it is happening except that the stack gets de-initalised sometimes in the project code and re-initalised. But just doing that a few 100 times has bot produced the problem. It may take from 2 hours to 48 hours before the problem occurs. If anyone has any ideas of the possible cause, or what else I can try, please let me know. Best regards X |
|
相关推荐
11个回答
|
|
当你体验到这个和硬件平台时,请指定你正在运行的演示。此外,和谐的确切版本将有助于(查看你正在运行的演示应用程序的SyrSoCyf.h)。第一个要澄清的事情是为什么TCP/IP栈被去初始化,什么事件T?安装此调用以关闭堆栈?试着设置一个断点并检查这个调用的确切位置。希望这会带来一些启发。
以上来自于百度翻译 以下为原文 Please specify the demo you're running when you experience this and the hardware platform. Also, the exact version of Harmony would help (look into the system_config.h for the demo app that you're running). The 1st thing to clarify would be why is the TCP/IP stack getting de-initialized, what event triggers this call to shut down the stack? Try to set a breakpoint and check where exactly this is called from. Hopefully this will throw some light. |
|
|
|
你好,Runad,GROMPE和声版本是2.04i,我不确定你的演示应用程序是什么意思。这是一个真正的应用程序。当以太网电缆被拉开,然后重新初始化时,堆栈就被取消了。我不知道为什么这样做,但是历史注释表明连接不能再被覆盖的问题。在任何情况下,堆栈应该能够。去初始化和重新初始化100%的时间。而且,95%的时间似乎起作用了。此外,堆删除问题是非常关心的。我已经尝试过代码,但无济于事。我不知道还有什么我可以尝试的时刻。
以上来自于百度翻译 以下为原文 Hello rainad, group The harmony version is 2.04 I am not sure what you mean by demo app. This is a real application. The stack gets de-initalised on purpose when the ethernet cable is pulled and then re-initalised. I don not know why this was done but the history comments indicate that there were problems with connections not able to be re-covered. In any case, the stack should be able to de-initalise and re-initialise 100% of the time. And, 95% of the time it seems to work. Also that heap deletion problem is very concerning. I have tried stepping through the code but to no avail. I am not sure what else I can try at the moment. |
|
|
|
好吧,我觉得这是一个和谐的演示。我认为它是一个自定义应用程序-在电缆断开时不需要重新启动堆栈,但可能有一些问题需要用这种方法来解决。不管怎样,你是对的,把栈倒下来,然后在没有问题的情况下完成工作。-“堆删除失败!”意味着仍然有模块分配的数据,因此堆不能被释放。之后,另一个分配尝试作为另一个调用初始化的一部分通常会失败,堆栈将不运行。当然,网络上的板是不可访问的。什么模块仍然对它的缓冲器保持……很难说。例如,它可以是应用程序,如果它不处理待定的UDP缓冲区。您可以启用TeTCPIPthStaskFraseTraceEngEnabl,并且可以使用控制台中的“HeAPFipe”来查看哪些模块仍然分配了数据。-另一个测试是为应用程序选择外部堆并查看如果这种行为更好。使用外部堆,TCP/IP堆栈不管理堆本身。但是,如果某个地方内存不足,最终你会注意到它。-但是事实上,你得到了例外,这真的很糟糕。在Mac驱动程序中,我很久没有听到这样的事情了。它可以是任何东西,甚至是ISR或其他代码,可以在MAC驱动程序维护的列表上执行。您可以尝试更新到堆栈的最新版本(不需要替换整个和声框架,您可以只尝试更新堆栈,希望它能建立OK)并运行测试,看看是否有E有任何变化。虽然这里似乎有更深层次的问题。
以上来自于百度翻译 以下为原文 OK, I thought this was a demo distributed with Harmony. I take it it is a custom application. - There shouldn't be any need to restart the stack when the cable is disconnected, but probably there was some issue that needed to be solved with this approach. Anyway, you're right, turn stack down and then up shold work without any problems. - The message ""Heap Delete fail!" means that there's data still allocated by the modules, so the heap could not be freed. After that, another allocation attempt as part of the another call to Initialization will normally fail and the stack won't be running. Of course the board won't be accessible on the network. What module still holds on to its buffers...hard to say. For example it could be the application, if it doesn't process the pending UDP buffers. You can enable the TCPIP_STACK_DRAM_TRACE_ENABLE and you'll be able to use "heapinfo" from the console to see what module still has allocated data. - Another test is to select the external heap for your app and see if this behaves better. With an external heap, the TCP/IP stack does not manage the heap itself. But if there is a memory leak somewhere, eventually you're going to notice it anyway. - But the fact that you're getting exceptions, this is really bad. And I haven't heard in a long while of something like this in the MAC driver. It could be anything, even an ISR or some other code that steps over the MAC driver maintained lists. You can try to update to the latest version of the stack (no need to replace the whole Harmony framework, you can try only updating the stack, hopefully it will build OK) and run a test, see if there's any change. Although it seems that there are deeper issues here. |
|
|
|
根据您的建议,我刚刚定义了TCPIpHytStAgJavaRead,TraceEngBayLaye,还必须定义TCPIpHyStActhFraseDebug,但是,我没有您提到的控制台,并且不能在EpARTARDO的任何地方找到“HeAPFipe”,在USAART2上有调试输出,但我需要知道在那里输出什么“HeAPFEPO”
以上来自于百度翻译 以下为原文 Thanks for that great info. As per your suggestion, I just defined TCPIP_STACK_DRAM_TRACE_ENABLE I also had to #define TCPIP_STACK_DRAM_DEBUG_ENABLE However, I do not have that console you mentioned and cannot find "heapinfo" anywhere in the project I do have debug output on USART2 but I would need to know what to output there for the "heapinfo" |
|
|
|
如果没有一个控制台来键入命令,那么只需查看实现该功能并尝试以某种方式复制该函数的TCPIPSIOrth.C::Oracle命令HeAPIN()函数。或者让它成为一个公共功能,可以从外部访问并调用它来显示正在发生的事情。当然,这将需要对UART端口进行轻微修改。希望这将显示什么模块不释放它的数据。P.S.从那个函数中,您只需要处理跟踪的部分:TCPIPHeHAPAPTraceGeEngEnter()部分。其余的与您的测试无关。
以上来自于百度翻译 以下为原文 If you don't have a console to type in commands, then just take a look into the tcpip_commands.c::_Command_HeapInfo() function that implements that functionality and try to replicate it somehow. Or make it a public function that can be accessed from the outside and call it to display what's going on. Of course it will require slight modifications to work with your UART port. Hopefully that will show what module doesn't release its data. P.S. From that function you need only the part that deals with the trace: TCPIP_HEAP_TraceGetEntry() portion. The rest is irrelevant for your test. |
|
|
|
|
|
|
|
我现在已经通过我的调试USAT端口将Fu7NcCutt操作了。这个看起来有用吗?如果是这样,你认为我应该在问题发生后从异常处理程序中运行它吗?注意:我看到模块10似乎比堆大小分配了更多的字节。有意义吗?
以上来自于百度翻译 以下为原文 I have now jacked that fu7nction to operate through my debug USART port. Does this look usable? 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoHeap type: 1. Initial created heap size: 57152 Bytes 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoAllocable block heap size: 57024 Bytes 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoAll available heap size: 57024 Bytes 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoLast heap error: 0x0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoTrace info: 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 1, tAlloc: 36608, currAllc: 2048, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 2, tAlloc: 512, currAllc: 0, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 9, tAlloc: 2144, currAllc: 0, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 10, tAlloc: 62752, currAllc: 0, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 12, tAlloc: 224, currAllc: 0, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 15, tAlloc: 1536, currAllc: 0, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_INFO HEAP_InfoModule: 23, tAlloc: 13312, currAllc: 0, totFail: 0, maxFail: 0 2018-07-26 11:35:59 S SYS_ERROR_DEBUG TCP/IP Stack: end of KillStack If so, Do you think I should run that from the exception handler after the problem occurs? NOTE: I see that Module 10 seems to have more bytes allocated than the heap size. Is that significant? |
|
|
|
TCPIP在初始化时分配一大块内存。当你关闭它它返回它。如果您的程序从该块分配,那么当您再次启动TCPIP堆栈时,可能不再有足够大的块用于MALOC。最简单的解决方案是不关闭堆栈,修复原来的问题,这是一个工作。否则,我确信当堆栈被关闭时,你不会使用MALOC。或者MALOC块将它保存到堆栈中。或者让堆更大。
以上来自于百度翻译 以下为原文 The tcpip allocates a big chunk of memory when it initlizes. When you shut it down it returns it. If your program allocates from that block there may no longer be a big enough block for the tcpip stack to malloc when you start it again. The easiest solution is to not shut down the stack and fix the original issue that this was a work around for. Otherwise I sure you do not malloc while the stack is shut down. Or malloc the block to hold it for the stack. Or make the heap bigger. |
|
|
|
当然,但问题是在去初始化/关机期间发生的,而不是新初始化。还有其他的协调模块在做Maloc等,特别是密码模块。我们的代码不执行任何操作。
以上来自于百度翻译 以下为原文 Sure but the problem happens during the de-initialistion/shutdown and not the new initialisation. There are other Harmony modules doing malloc etc. Particularly the Crypto modules. Our code does not do any. |
|
|
|
从调试这一点来看,在我看来,在HeAPuxFipe中,模块1 CurrutoLoC每次堆栈被杀死,然后重新初始化时,会增加大约900字节左右。我想可能是漏掉了内存。
以上来自于百度翻译 以下为原文 From debugging this, it appears to me that in the HEAP_info, module 1 currentAlloc goes up by about 900 or so bytes every time the stack is killed and then re-initialised. I reckon it is possibly leaking memory. |
|
|
|
到目前为止,我只是建立了堆栈用Maloc调用和CaloC调用初始化。对于模块1,我已经打印了所有的CaloC和Maloc并添加了字节。在终止时,我打印了所有的免费调用,并把字节加在一起。似乎有1088字节的差异。T显示没有CALLoc分配的字节再次被释放。MALLC调用都有一个匹配的空闲。正在进行调查。
以上来自于百度翻译 以下为原文 So far, I have only established that the stack initialises with malloc calls and calloc calls. For Module 1 I have printed all the calloc and malloc and added the bytes together. On termination, I printed all the free calls and added the bytes together as well. There seems a difference of 1088 bytes. It appears that none of the calloc assigned bytes get freed again. The malloc calls all have a matching free. Investigation ongoing... |
|
|
|
只有小组成员才能发言,加入小组>>
5166 浏览 9 评论
2000 浏览 8 评论
1928 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3174 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2226 浏览 5 评论
734浏览 1评论
615浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
505浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
631浏览 0评论
528浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-24 12:40 , Processed in 1.280911 second(s), Total 67, Slave 61 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号