weixin_39598069
weixin_39598069
2020-11-25 17:48

transfer timeout

I'm attempting to create interface firmware for my custom platform (xDot) based on the Freescale KL17 processor. I have been able to build interface firmware, but it isn't able to flash the target processor. I enabled debug logging in the interface firmware and always get the same bunch of messages:

vfs_manager file_change_handler(name= Ax, file=200000a0, change=2) vfs_manager file_change_handler(name=XDOT-T~1BIN , file=200000c0, change=2) vfs_manager file_change_handler(name=XDOT-T~1BIN , file=200000c0, change=0) vfs_manager transfer_update_file_info(file=200000c0, start_sector=37, size=38980) file_to_program=200000c0 start_sector=37 stream=0 updated size=38980 vfs_mngr_periodic() time_usb_idle=20160 transfer_state=1 state 2->1 transfer timeout vfs_manager transfer_update_state(status=0) file=200000c0, start_sect= 37, size=38980 stream=0, size_processed=0, opt_finish=0, timeout=1 Transfer finished, status: 4=The transfer timed out. vfs_mngr_periodic() time_usb_idle=2610 transfer_state=3 state 1->2

FAIL.TXT always says "The transfer timed out."

I had previously removed an interface chip from a kl43 dev board and put it on mine. This setup was able to successfully program the KL17 target. With that in mind, I used the KL43 flash algorithm from the FlashAlgo repository.

I'm not a JTAG/SWD expert and I'm not terribly familiar with the DAPLink codebase. I've spent time browsing the code and trying to trace back to where the error is coming from, but I haven't had any luck.

I built the bootloader using DAPLink repo and that works fine. I noticed that there are multiple binaries that get generated when I build the interface firmware

k20dx_xDot_if.bin k20dx_xDot_if_crc.bin k20dx_xDot_if_crc_legacy_0x5000.bin k20dx_xDot_if_crc_legacy_0x8000.bin

I've been using the first one. Should I be using one of the others?

I don't think I have any major hardware problems since my device worked after I swapped interface chips. Does this look familiar to anybody? Can anyone explain in more detail what this error & series of log messages means? Does this point to my flash algorithm or target configuration, or something else entirely?

I've attached a diff of my changes from rev 8e14abbfaeeffab78d7307e22445efaa58501411. diff.txt

该提问来源于开源项目:ARMmbed/DAPLink

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

7条回答

  • weixin_39526872 weixin_39526872 5月前

    Hi , I would recommend using k20dx_xDot_if_crc.bin, especially if you are using a DAPLink bootloader.

    From the logs it looks like the binary you have doesn't have a valid vector table, or the info in target.c is out of date. If you could send the target binary and target.c file I can take a look and let you know if this is the case.

    点赞 评论 复制链接分享
  • weixin_39598069 weixin_39598069 5月前

    Thanks for your quick reply, !

    I tried k20dx_xDot_if_crc.bin, but got the same results.

    I've attached target.c and both binaries - had to add a .txt to the name of each to make GitHub happy. target.c.txt k20dx_xDot_if.bin.txt k20dx_xDot_if_crc.bin.txt

    点赞 评论 复制链接分享
  • weixin_39526872 weixin_39526872 5月前

    Hi , can you attach the KL17 binary that you are trying to program?

    点赞 评论 复制链接分享
  • weixin_39598069 weixin_39598069 5月前

    Here you go! Thanks again for helping me out!

    xdot-test.bin.txt

    点赞 评论 复制链接分享
  • weixin_39526872 weixin_39526872 5月前

    Looks like ram_end is one byte too short - 0x20005FFF should be 0x20006000. Try this target file: target.c.txt

    点赞 评论 复制链接分享
  • weixin_39598069 weixin_39598069 5月前

    Wow, that did it. I really shouldn't have missed that. Thanks for you help & consider this case closed.

    点赞 评论 复制链接分享
  • weixin_39526872 weixin_39526872 5月前

    Glad I could help :smile:

    点赞 评论 复制链接分享

相关推荐