[U-Boot] loadb problem. Hangs on START_CHAR

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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-tp195144p195379.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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

-- 
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 at denx.de
"If the code and  the  comments  disagree,  then  both  are  probably
wrong."                                                - Norm Schryer

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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-tp195144p195381.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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-tp195144p196499.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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

-- 
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 at denx.de
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
                                           - Antoine de Saint-Exupery

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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-tp195144p196515.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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

-- 
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 at denx.de
The human mind treats a new idea the way the body  treats  a  strange
protein - it rejects it.                                 - P. Medawar

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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-tp195144p196541.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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

-- 
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 at denx.de
"Now here's something you're really going to like!"
- Rocket J. Squirrel

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

"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-tp195144p196545.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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 at 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

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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

-- 
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 at denx.de
...when fits of creativity run strong, more than  one  programmer  or
writer  has  been  known to abandon the desktop for the more spacious
floor.                                             - Fred Brooks, Jr.

[U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

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-tp195144p196549.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

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

-- 
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 at denx.de
Use the Force, Luke.

[U-Boot] loadb problem. (was: Hangs on START_CHAR)

[bomellberg]

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-tp195144p196574.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] [SOLVED] loadb problem.

[bomellberg]

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-tp195144p196641.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] [SOLVED] loadb problem.

[Wolfgang Denk]

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

-- 
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 at denx.de
Mirrors should reflect a little before throwing back images.
- Jean Cocteau

[U-Boot] [SOLVED] loadb problem.

[bomellberg]

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-tp195144p196714.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] [SOLVED] loadb problem.

[Wolfgang Denk]

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

-- 
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 at denx.de
"You ain't experienced..." "Well, nor are you." "That's true. But the
point is ... the point is ... the point is we've been not experienced
for a lot longer than you. We've got  a  lot  of  experience  of  not
having any experience."           - Terry Pratchett, _Witches Abroad_