[U-Boot] loadb problem. Hangs on START_CHAR
Hi.
I'm working on getting u-boot running on a custom board. I am using code from Emcraft as a starting point. The cpu is NXP LPC4337. The board has external SDRAM and SPIFI flash, but no wired network.
I can boot u-boot fine, and I can perform some memory operations with md and mw.
I can load the Hello World standalone example using loads and run it with go.
I cannot use the loadb command though. The transfer hangs at the beginning. Using some crude printing debugging I found that the START_CHAR is not received.
From cmd_load.c:
I never get the "S", so the transfer never starts. I have tried Tera Term on Windows and C-Kermit on Linux, using the settings mentioned in the DULG. I have tried two different USB-to-RS232-3.3V dongles.
A search in the archives shows a possible explanation in FIFO byte order, but I cannot find a place to alter this. Could it be the FIFO byte order for the UART is important for the kermit transfer, but not for the console?
An oscilloscope picture of the kermit transfer's first bytes: http://u-boot.10912.n7.nabble.com/file/n195144/tek00002.png It sure looks like a 0x01 as the first byte. But the code doesn't reach the "S" debug.
If I send 0x01 using RealTerm, I get the "S" debug. I can't figure this out.
Thankful for any help.
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Upon further investigation, it seems like the board DOES receive the 0x01 START_CHAR. An RS232 sniffer shows that the 0x01 is being sent, and the board answers 'S'. It does not show on the console though.
I will need to go deeper into the code to see why it fails. Both CKermit and TeraTerm makes several tries, but nothing is transferred.
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear bomellberg,
In message 1415622808801-195379.post@n7.nabble.com you wrote:
Upon further investigation, it seems like the board DOES receive the 0x01 START_CHAR. An RS232 sniffer shows that the 0x01 is being sent, and the board answers 'S'. It does not show on the console though.
I will need to go deeper into the code to see why it fails. Both CKermit and TeraTerm makes several tries, but nothing is transferred.
I just tested "loadb" on a MPC5200 system running current top of tree against C-Kermit 8.0.211, 10 Apr 2004, for Linux; it works without any problems here.
Which sort of hardware are you using?
Best regards,
Wolfgang Denk
Dear Wolfgang,
Which sort of hardware are you using?
I am using an NXP LPC4337 cpu with external SDRAM and SPIFI flash. No ethernet.
My config files are based upon code for the Embedded Artists LPC4357 demo board (ea-lpc4357.h) See my first post.
Thanks,
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Some progress...
If I turn down the baud rate to 9600, as well as set a line delay of 100 ms, the loadb transfer works, and I get 0x240 bytes of Hello World at the address of my choice.
So, it seems to be some kind of baud rate missmatch between my board and the PC. The console works fine in 115200 baud, so I'm a bit lost here. Does kermit require slow transfers?
Feel free to chip in.
Thanks,
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416218063825-196499.post@n7.nabble.com you wrote:
If I turn down the baud rate to 9600, as well as set a line delay of 100 ms, the loadb transfer works, and I get 0x240 bytes of Hello World at the address of my choice.
So, it seems to be some kind of baud rate missmatch between my board and the
You may want to attach a scope and measure the timing, then.
PC. The console works fine in 115200 baud, so I'm a bit lost here. Does kermit require slow transfers?
No, not at all. On contrary, the whole design is set up to provide fastest binary download as permitted by the baud rate.
Did you include these options in your port settings?
set carrier-watch off set handshake none set flow-control none set file type bin set file name lit set rec pack 1000 set send pack 1000 set window 5 robust
?
Best regards,
Wolfgang Denk
Wolfgang,
Yes, those settings are all in my .kermrc setup.
I measured the fastest pulse on my scope to 8.691 µs, which gives 1/(8.691 x 1e-6) = 115061.56 baud. Not really 115200 but is it too far from working in your opinion? The tolerance in RS232 signalling is about 50% of the minimum pulse width for a byte which would be about 113000 - 117000 baud.
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416225420788-196515.post@n7.nabble.com you wrote:
Yes, those settings are all in my .kermrc setup.
OK. Just checking to make sure we don;t miss anything.
I measured the fastest pulse on my scope to 8.691 µs, which gives 1/(8.691 x 1e-6) = 115061.56 baud. Not really 115200 but is it too far from working in your opinion? The tolerance in RS232 signalling is about 50% of the minimum pulse width for a byte which would be about 113000 - 117000 baud.
That's just 0.12% off, this should not be the problem.
Did you measure both directions (Tx on PC, and Tx on target) ?
Best regards,
Wolfgang Denk
Well, I measured TX and RX at the target. They both have the same minimum pulse width of about 8.7 µs.
I'm reading up on delays in c-kermit. Is there a way to set char- and line delays somehow?
In Tera Term for Windows you can set them but they seem to have no effect on Kermit transfers, only on the console.
Thank you,
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416227882897-196541.post@n7.nabble.com you wrote:
Well, I measured TX and RX at the target. They both have the same minimum pulse width of about 8.7 µs.
I'm reading up on delays in c-kermit. Is there a way to set char- and line delays somehow?
You should not need any such delays. The protocol is simple enough. Even a slow processor should have ample resources to handle this - I think I had this working on some ancient MPC860 PowerPC system running at just 33 MHz CPU clock.
What is your CPU clock?
You do have caches enabled, don't you?
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this res- pect they outnumber all the other known creatures about four to one. -- Professor Snope's Encyclopedia of Animal
Dear Wolfgang!
Thank you for your efforts to help me out.
I keep coming back to the fact that "loads" works fine in 115200 baud, but "loadb" does not.
If there is indeed a timing issue, it must be some handshaking in the Kermit protocol, right? The "loads" command just absorbs data as it is transferred, but the "loadb" command, using Kermit, tries to speed up the transfer by adjusting packet size according to crc-errors.
I am a bit baffled as you can imagine.
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416231868926-196549.post@n7.nabble.com you wrote:
I keep coming back to the fact that "loads" works fine in 115200 baud, but "loadb" does not.
This is the funny part of it.
If there is indeed a timing issue, it must be some handshaking in the Kermit protocol, right? The "loads" command just absorbs data as it is transferred, but the "loadb" command, using Kermit, tries to speed up the transfer by adjusting packet size according to crc-errors.
But you don't even get there. You write you get stuck at the START_CHAR - eventually there is a bug in the serial driver or even in the hardware, such that it is not really 8 bit clean, or enables parity or such. "loads" s just an ASCII text transfer, i. e. it works fine when you get only 7 data bits through. "loadb" will really need an 8 bit clean link.
I am a bit baffled as you can imagine.
Me too.
Best regards,
Wolfgang Denk
Sorry for the confusion. Using an rs232 sniffer I found that the Start_char IS sent to the PC, see some posts ago.
Fyi, "loady" also works. It types 'C' every 4 seconds until I start the ymodem transfer, and then it uploads the code ok.
When using "loadb", I can see on the scope that data is being sent, and that the board answers. The PC does not seem happy with the answer though, because it sends the first packet over and over.
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416225420788-196515.post@n7.nabble.com you wrote:
I measured the fastest pulse on my scope to 8.691 µs, which gives 1/(8.691 x
...
Re-reading this I stumble over "the fastest pulse". Did you also verify that the bit widths are all the same?
What about the stop bit settings? Are both sides set to 8N1?
Best regards,
Wolfgang Denk
"The fastest pulse" = the time that one bit encompasses.
The following picture shows sending the character 'U' (0x01010101):
http://u-boot.10912.n7.nabble.com/file/n196545/tek00004.png
Channel 1 shows the 'U' sent from the PC. Channel 2 shows the 'U' sent as reply from the board, which is also displayed on the console. To me it seems fine, with a trailing stop bit as well.
I have not altered the 8N1 configuration in the config files for the board. The only change is the use of USART3 instead of USART0. The PC is set to 8N1-115200.
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416230584402-196545.post@n7.nabble.com you wrote:
The following picture shows sending the character 'U' (0x01010101):
http://u-boot.10912.n7.nabble.com/file/n196545/tek00004.png
Channel 1 shows the 'U' sent from the PC. Channel 2 shows the 'U' sent as reply from the board, which is also displayed on the console. To me it seems fine, with a trailing stop bit as well.
Indeed, this looks fine to me as well. Strange.
Best regards,
Wolfgang Denk
Dear Wolfgang,
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.
Thank you for your time. Hopefully this can help someone in the future.
/Bo
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
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
The TESTING variable was defined to debug the Spifilib library that is needed for quad spi flash on lpc cpus.
As you can see in the very first post, I made some printfs and a 10 ms delay. I removed those as well, so in the end perhaps they were the culprit.
I had a previous loady problem, which was definately solved by commenting out all Debugs.
-- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144... Sent from the U-Boot mailing list archive at Nabble.com.
Dear Bo,
In message 1416343564051-196714.post@n7.nabble.com you wrote:
The TESTING variable was defined to debug the Spifilib library that is needed for quad spi flash on lpc cpus.
As you can see in the very first post, I made some printfs and a 10 ms delay. I removed those as well, so in the end perhaps they were the culprit.
I had a previous loady problem, which was definately solved by commenting out all Debugs.
All understood. I'm happy you got the system running.
Best regards,
Wolfgang Denk
participants (2)
-
bomellberg -
Wolfgang Denk