[ECOS] DBG Serial Init Problem with MBX based code

[ECOS] DBG Serial Init Problem with MBX based code

[Ross Wightman]

Yup, it worked. The serial port gets initialized and GDB can communicate
with the board. Now I'm having issues loading programs onto the board. No
matter what baud rate I use (even slowing it to 9600) the program download
process downloads the vectors at a good rate, then when it gets to .text
the download goes up in increments of 512bytes about every 30 seconds with
lots of packet error warnings in the gdb console. Sigh, the fun never
ceases.  

(Btw sorry bout not replying to the thread, but that doesn't seem to work)

Jesper Skov <jskov@redhat.com> wrote in message
news:8oib37$3fv$1@velvet.microplex.com ...
> >>>>> "Ross" == Ross Wightman <rpw@velvet.microplex.com> writes:
> Ross> This problem would be easy to "hack" fix. However, I would like
> Ross> some insight into why this is setup as is (if it should be?) and
> Ross> what a good fix would entail.
> 
> I think something like the below is what we want. Could you please see
> if it fixes your problem - if so, I will commit it.
> 
> Ta,
> Jesper

Re: [ECOS] DBG Serial Init Problem with MBX based code

[Jesper Skov]

>>>>> "Ross" == Ross Wightman <rpw@velvet.microplex.com> writes:

Ross> Yup, it worked. The serial port gets initialized and GDB can
Ross> communicate with the board. Now I'm having issues loading
Ross> programs onto the board. No matter what baud rate I use (even
Ross> slowing it to 9600) the program download process downloads the
Ross> vectors at a good rate, then when it gets to .text the download
Ross> goes up in increments of 512bytes about every 30 seconds with
Ross> lots of packet error warnings in the gdb console. Sigh, the fun
Ross> never ceases.

Thanks, committed.

Sorry, no idea about the other problem. But try to force ASCII
download and enable debugging so you can see what's happening on the
line:

(gdb) set remotebinarydownload 0
(gdb) set remotedebug 1

If you see nothing weird, it could be a problem with the cable or the
board/PC connectors.

Also, you may want to try running GDB in CLI-mode (use -nx when
starting it) to see if that might make a difference (stranger things
have happened).

Jesper

Re: [ECOS] DBG Serial Init Problem with MBX based code

[Jesper Skov]

>>>>> "Ross" == Ross Wightman <rpw@velvet.microplex.com> writes:
Ross> This problem would be easy to "hack" fix. However, I would like
Ross> some insight into why this is setup as is (if it should be?) and
Ross> what a good fix would entail.

I think something like the below is what we want. Could you please see
if it fixes your problem - if so, I will commit it.

Ta,
Jesper


Index: ChangeLog
===================================================================
RCS file: /local/cvsfiles/ecc/ecc/hal/powerpc/quicc/current/ChangeLog,v
retrieving revision 1.26
diff -u -5 -r1.26 ChangeLog
--- ChangeLog	2000/06/30 08:30:55	1.26
+++ ChangeLog	2000/08/30 06:50:58
@@ -1,5 +1,10 @@
+2000-08-30  Jesper Skov  <jskov@redhat.com>
+
+	* src/quicc_smc1.c (cyg_hal_plf_serial_init_channel): Move all
+	init code to init_channel.
+
 2000-06-30  Jesper Skov  <jskov@redhat.com>
 
 	* src/quicc_smc1.c: calling i/f macro changes.
 
 2000-06-28  Jesper Skov  <jskov@redhat.com>
Index: src/quicc_smc1.c
===================================================================
RCS file: /local/cvsfiles/ecc/ecc/hal/powerpc/quicc/current/src/quicc_smc1.c,v
retrieving revision 1.25
diff -u -5 -r1.25 quicc_smc1.c
--- src/quicc_smc1.c	2000/06/30 08:30:55	1.25
+++ src/quicc_smc1.c	2000/08/30 06:52:44
@@ -91,19 +91,26 @@
  */	
 void
 cyg_hal_plf_serial_init_channel(void)
 {
     EPPC *eppc;
+    int i;
     volatile struct smc_uart_pram *uart_pram;
     struct cp_bufdesc *txbd, *rxbd;
 
     static int init_done = 0;
     if (init_done) return;
     init_done++;
 
     eppc = eppc_base();
 
+    /*
+     *  Reset communications processor
+     */
+    eppc->cp_cr = QUICC_CPM_CR_RESET | QUICC_CPM_CR_BUSY;
+    for (i = 0; i < 100000; i++);
+
     /* SMC1 Uart parameter ram */
     uart_pram = &eppc->pram[2].scc.pothers.smc_modem.psmc.u;
 
     /* tx and rx buffer descriptors */
     txbd = (struct cp_bufdesc *)((char *)eppc + Txbd);
@@ -458,21 +465,14 @@
 cyg_hal_plf_serial_init(void)
 {
     hal_virtual_comm_table_t* comm;
     int cur = CYGACC_CALL_IF_SET_CONSOLE_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);
     volatile EPPC *eppc = eppc_base();
-    int i;
 
     static int init = 0;  // It's wrong to do this more than once
     if (init) return;
     init++;
-
-    /*
-     *  Reset communications processor
-     */
-    eppc->cp_cr = QUICC_CPM_CR_RESET | QUICC_CPM_CR_BUSY;
-    for (i = 0; i < 100000; i++);
 
     cyg_hal_plf_serial_init_channel();
 
     // Setup procs in the vector table
 

[ECOS] DBG Serial Init Problem with MBX based code

[Ross Wightman]

Okay, thanks to Gary's help I now appear to have the memory aspects of
eCos working on my board. 

I have now run into a new problem with the debug serial channel
initialization. In the mbx code from CVS the fcn
cyg_hal_plf_serial_init_channel() initially gets called from hal_diag_init 
during some constructor/initializer code. A little later on, the fcn
cyg_hal_plf_serial_init() in quicc_smc1.c gets called. This function
resets the CPM right before it makes a call to serial_init_channel()
again. The CPM reset wipes almost everything that the initial call to
serial_init_channel set up and due to the fact that serial_init_channel()
has a check so that it can only be run once, the channel is not setup back
up again. 

This problem would be easy to "hack" fix. However, I would like some
insight into why this is setup as is (if it should be?) and what a good
fix would entail.

Thanks.