完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
你好。我使用的是Microchip和声V2Y04 04 TCP协议栈。我得到工作Web,我希望通过卷曲更新它。但到目前为止,每当我试图在PIC中上传图像文件时,我就发现了SimeTyTLBReFrILL异常处理程序。上传文件通过/MPFSUPPLAD工作精细。为什么会这样?
以上来自于百度翻译 以下为原文 Hello. I'm using Microchip HARMONY v2_04 TCP stack. I got working WEB, and I wish to update it via curl. But so far I got _simple_tlb_refill_exception_handler every time I'm trying to upload image file in PIC. Uploading file via /mpfsupload working fine. Why is this so? |
|
相关推荐
2个回答
|
|
好的,这是我找到的。通过浏览器/MPFSUPPLAD页面上传文件创建两个TCP包。一个是标题(帖子、密码等)和/r/n/r/n空字符串。第二个是2974个字节,更多的报头(缓存控制和内容类型,然后是另一个/r/n/r/n和MPFS/ 01/02签名)。文件上传过程TCPIPPHTTPYMPFSUPPLAUD()(在http.c)查找第二个“/r/n/r/n”,如果没有发现它丢弃当前TCP包并等待另一个包:这在WiReSARK中是什么样子:到目前为止是如此好。但是如果我们使用CURL,则它发送数据在三个TCP包中,316, 210个和7354个字节,其中MPFS签名位于FILD包的开始(见图)。因此,TCPIPPHTTPYMPFSUPPLAUDE()无法找到任何“/r/N/R/N MPFS/01/02”字符串,最终无法达到这个奇怪的TLB异常。现在,我通过检查“/R/N/R/N MPFS/01/02”,而不是“MPFS/01/02”字符串来修复这个问题,尽管我不确定这是否是100%正确的。感谢您的意见。修补代码:
以上来自于百度翻译 以下为原文 OK, here is what I found. Uploading file via browser's /mpfsupload page creates two TCP packets. One is with headers (POST, password etc) and /r/n/r/n empty string. Second is 2974 bytes, more headers (cache-control and content type, then another /r/n/r/n and MPFS/01/02 signature). File upload procedure TCPIP_HTTP_MPFSUpload() (in http.c) looks for second "/r/n/r/n", and if didn't find it discards current TCP packet and waits for another one: case HTTP_MPFS_UP: pHttpCon->uploadSectNo = 0; lenA = TCPIP_TCP_ArrayFind(pHttpCon->socket, (const uint8_t*)"rnrn", 4, 0, 0, false); //here we check for rnrn if(lenA != 0xffff) {// Found it, so remove all data up to and including //skipped some code if(memcmp(nvmBuffer, (const void*)MPFS_SIGNATURE, sizeof(MPFS_SIGNATURE)-1) == 0) //here we check for MPFS signature Here how this looks like in Wireshark: So far so good. But if we are using CURL, it sends data in three TCP packets, 316, 210, and 7354 bytes, in which MPFS signature located in very beginning of fird packet (see picture). Therefore, TCPIP_HTTP_MPFSUpload() can't find any "/r/n/r/n MPFS/01/02" string, and eventually failing to this odd TLB exception. For now, I fixed this by checking not "/r/n/r/n MPFS/01/02", but "MPFS/01/02" string, though I'm not sure if this is 100% correct. Comments are appreciated. Patched code: case HTTP_MPFS_UP: pHttpCon->uploadSectNo = 0; lenA = TCPIP_TCP_ArrayFind(pHttpCon->socket, (const uint8_t*)MPFS_SIGNATURE, sizeof(MPFS_SIGNATURE)-1, 0, 0, false);if(lenA != 0xffff) {// Found it, so remove all data up to and including lenA = TCPIP_TCP_ArrayGet(pHttpCon->socket, NULL, lenA + sizeof(MPFS_SIGNATURE)-1); pHttpCon->byteCount -= (lenA + sizeof(MPFS_SIGNATURE)-1); if(1) { // Read as Ver 2.1 // allocate the buffer size as a multiple of sector size mpfsAllocSize = ((MPFS_UPLOAD_WRITE_BUFFER_SIZE + (SYS_FS_MEDIA_SECTOR_SIZE - 1)) / SYS_FS_MEDIA_SECTOR_SIZE) * SYS_FS_MEDIA_SECTOR_SIZE; |
|
|
|
我会仔细研究并提供一个解决方案。同时请使用你的解决方案。不管怎样,堆栈不应该崩溃,RN是否存在。它应该在那里。当我有东西的时候我会更新。谢谢你的报道。
以上来自于百度翻译 以下为原文 I'll be looking into this and provide a resolution ASAP. Meanwhile please use your workaround. No matter what, the stack should not crash, rn present or not. It should be there though. I'll update when I have something. Thank you for reporting this. |
|
|
|
只有小组成员才能发言,加入小组>>
5209 浏览 9 评论
2017 浏览 8 评论
1943 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3189 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2244 浏览 5 评论
759浏览 1评论
647浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
565浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
658浏览 0评论
557浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-10 09:20 , Processed in 1.038211 second(s), Total 46, Slave 41 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号