Re: [U-Boot-Users] Problems using UART1 instead of UART0

Hi TsiChung,
First, thanks! And second, sorry about the last ramble; it was late, and after nearly 16 hours at it, I needed a break! Third, I'm on vacation for a week starting tomorrow, and on another project today, so things will have to wait a bit. But I do owe you an explanation of where things sit. This is a bit long, and not time-critical, so feel free to set it aside for when you need a bit of comic relief!
After emailing last, I tried a few experiments, and in thinking about the results this morning on the train, I am almost entirely certain the problem is somewhere in my hack to attempt to run out of RAM. What threw me on a long detour was an apparent flaky serial port. Late yesterday I realized that swap I mentioned in my first post, and what had appeared to be working software and flaky hardware actually was non-working software and working, though deceptive, hardware. What I had thought was the board responding to keyboard input via the serial port was in fact, a reflection of the received data on uart 0 being transmitted out the unused uart 1. Specifically, my theory is that because the uart 1 transmit pin was not being set as an output, and thus were left presumably floating, the received data arriving at the shared transceiver chip was strong enough to influence the input to the transceiver to case phantom transmission on the idle port - hence, the board, and more specifically, the software, seemed to be working. Hence also the timing seemed right!
When I changed to the correct port, nothing happened, and attempting to break out of GDB caused it to report several errors, all to the effect that the CPU had run away. So ultimately I thought there was an issue with uart 1 programming. Investigation of the code, which isn't always easy with all the configuration, macros, include and source files in vastly different areas of the tree (e.g. ./board, ./cpu, ./drivers, ./lib_m68k) made it terribly difficult to convince myself the software was okay or not.
Finally, I tried more carefully to debug what I thought was the working uart 0 version, and I finally noticed that breaking out from gdb wasn't working there either. Thinking about it this morning, I've realized that that version never was working to begin with! What I really understand now is that the problem lies in changing the clock near the beginning of startup, where uboot assumes it is running from flash - sdram gets corrupted, bam!
The real problem is either (or both) my erroneous assumption that CFFlasher would work to program my flash, or that the flash is bad. Because we have a different flash part, unless CFFlasher is using CFI, the first assumption is wrong - is that correct? Also, I got an algorithm for programming the flash with the P&E Micro tools, but that didn't work. So I figured I would use uboot, running out of RAM.
So I'm a bit stuck. My plan is to try a new algorithm with the P&E Micro tools; if that works, great! If not, I'm going to hack uboot to skip the clock change, adjust the baud rate calculation, and possibly skip the relocation; this last step is not necessary, IIRC. Once I get the hacked uboot-ram running from sdram, I'll use it to program the real uboot. Again, there _is_ a reason to run uboot from ram only!
Thanks for all your help, and sorry if I've been too much of a pain - no excuse save a panic rush to get something positive done before a much needed, if not necessarily deserved, vacation!
Take care, -Bob
On 8/24/07, Liew Tsi Chung-r5aahp Tsi-chung.Liew@freescale.com wrote:
Bob,
I'll get back on Monday to assist you.
Regards, TsiChung
-----Original Message----- From: Bob Grimes [mailto:rsg.uboot@gmail.com] Sent: Thursday, August 23, 2007 10:05 PM To: Liew Tsi Chung-r5aahp Subject: Re: Problems using UART1 instead of UART0
On 8/23/07, Liew Tsi Chung-r5aahp Tsi-chung.Liew@freescale.com wrote:
Bob,
To try the extra uart on M5329EVB, connect pin 78 uart1 rx and pin 77
uart1 tx, or pin 73 uart2 tx and pin 74 uar2 rx at J38. The signal is only TTL, you will need a transceiver to have it working.
I'll have to look into that, but I've been focusing on the customer's board... ;-)
As for your custom board, you might need to check your RCON
configuration. It could have the RCON set at default value or other than value specified in M5329EVB.h. Try to use oscope to check on the pin 24 of BDM header first to find out the CPU clock speed. Then use that freq to calculate your bus clock. The uart baud rate is based on the bus clock. If the bus freq increase or descrease ~4Mhz, it will affect the baudrate output.
Okay, now I am really confused.
- The RCON signal is not being used - it is pulled high with a 10k
resister to 3.3 V. 2. RCON register reads 0x0001, which indicates "normal" operation - right? 3. When uboot is configured for uart0 and I run it, I get bit widths about 8.5 us, which is close to 115,200 as expected. Not exactly, but I think there's significant measurement error. Anyway, this isn't the problem. 4. When running, I see a nice, solid 2 MHz on pin 24 of BDM header. 5. Oddly, FB_CLOCK is 1.333 MHz when running, pretty solid though. When I power up the board without the BDM, this is solid 60 MHz, as advertised.
So, don't know about much of this. Are these signals normal?
I don't know... I'm not sure if the processor is running or not, though. At this point, I think it's software and/or hardware. ;-) My current thinking is that there my attempt to run uboot only within ram is not working right, actually. Unfortunately, while I have BDM working, I can't program the Flash. I once got an old version (1.1.6?) working from RAM, but abandoned that for your 1.2 port, but that was on the m5329evb, so I could program that board's flash using CFFlasher, then debug using BDM. Now, what can I do? By the way, this is why one might want to run uboot from ram - to program the flash in the first place!!!
There doesn't seem to be any way to use CFFlasher with my board, even though it is very similar to the m5329evb - probably because we're using an 8 MB Atmel NOR flash chip..
Okay, I'm rambling, and best check out...
-Disgruntled Bob
Regards, TsiChung
-----Original Message----- From: Bob Grimes [mailto:rsg.uboot@gmail.com] Sent: Thursday, August 23, 2007 7:21 PM To: Das U-Boot Mailing List; Liew Tsi Chung-r5aahp Subject: Problems using UART1 instead of UART0
Hi,
I finally got our custom board, and unfortunately, the hardware guy seemed to have missed the message, and he's assigned the second mcf5329 uart to the console! Argh!
So I've tried changing CFG_UART_PORT from (0) to (1), but nothing
seems to happen. I've traced into some of the code, and have confirmed that the associated pins have been properly assigned to UART1. I'm having trouble determining anything more than that; specifically, I've yet to find the serial init code, as it seems to hang when setting the cpu clock speed. Probably not too surprising I can't debug through that code, but it doesn't seem to make it through.
Tsi Chung, have you tried this?
Back to the debugger, and code inspecting...
Thanks, -Bob
participants (1)
-
Bob Grimes