Dear Bo,
In message 1416300182202-196641.post@n7.nabble.com you wrote:
Upon looking at the transfers more closely on the scope, I found that the board sometimes answered the PC in the middle of receiving a packet. I found that this was due to a global DEBUG being turned on in the configuration file for the board.
When I removed all of the following:
#define DEBUG #define CONFIG_DEBUG_DUMP #define CONFIG_DEBUG_DUMP_SYMS #define CONFIG_DEBUG_EARLY_SERIAL #define CONFIG_DEBUG_NULL_PTR #define TESTING
the Kermit transfers are fine, with approximately 4 kilobytes per second transfer rate.
Ah, so obviously one of these options spits out data on the serial line, which then breaks the prtocol? We should find and fix that.
Let's see...
CONFIG_DEBUG_DUMP is only used in arch/blackfin/cpu/traps.c and arch/blackfin/cpu/cpu.c - that should not affect you.
CONFIG_DEBUG_DUMP_SYMS is only defined in include/configs/blackstamp.h and include/configs/blackvme.h but not used anywhere.
CONFIG_DEBUG_EARLY_SERIAL is also only defined in these two BF boards, and used only in BF code (arch/blackfin/cpu/cpu.c, arch/blackfin/include/asm/serial.h, and drivers/serial/serial_bfin.c).
CONFIG_DEBUG_NULL_PTR is only used in arch/blackfin/cpu/cpu.c - that should not affect you.
TESTING is nowhere used or defined in mainline code.
So unless you have added any such debug code to your own board specific code, the only potential culprit is DEBUG ...
But then, I cannot find any DEBUG or debug() or similar code in cmd_load.c ...
Can you please verify if you have added any such debug code in your local tree?
Thank you for your time. Hopefully this can help someone in the future.
You are welcome.
Best regards,
Wolfgang Denk