Loading ...
Sorry, an error occurred while loading the content.

MRM trouble!

Expand Messages
  • James Fitzsimons
    Hi all, I think I may have accidentally hosed CPU32Bug on my MRM. I ve been trying to get RTEMS running out of ROM on my MRM and have been having a lot of
    Message 1 of 12 , Feb 8, 2014
    • 0 Attachment
      Hi all,

      I think I may have accidentally hosed CPU32Bug on my MRM. 

      I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

      If I connect to the serial port using minicom I get the following:

      CPU32Bug Debugger/Diagnostics - Version  1.00                                  
       (C) Copyright 1991 by Motorola Inc.                       

      CPU32Bug>

      And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

      I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

      Anyone got any advice?

      Thanks!
      James Fitzsimons
    • Pat Tressel
      James -- I think I may have accidentally hosed CPU32Bug on my MRM. ... Not that it s any comfort, but apparently you re not the first to run into this...the
      Message 2 of 12 , Feb 8, 2014
      • 0 Attachment
        James --

        I think I may have accidentally hosed CPU32Bug on my MRM. 

        I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

        If I connect to the serial port using minicom I get the following:

        CPU32Bug Debugger/Diagnostics - Version  1.00                                  
         (C) Copyright 1991 by Motorola Inc.                       

        CPU32Bug>

        And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

        I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

        Not that it's any comfort, but apparently you're not the first to run into this...the following is from 10 years ago:

        http://list.dprg.org/archive/2004-July/025454.html

        Too bad there's no resolution...

        Can you tell if the re-flashing succeeds?  Is it possible that the modifications mentioned are not compatible?  (They sound benign...)  There's a footnote at the bottom that specifies 19200 baud -- is that what you're using?  Is your BDM cable ok?  (Scraping the bottom of the barrel here...)

        :-(

        -- Pat
      • James Fitzsimons
        Thanks for your reply Pat. It certainly looks like the re-flashing has finished successfully. I m going to use objdump tonight to look at the addresses of the
        Message 3 of 12 , Feb 9, 2014
        • 0 Attachment
          Thanks for your reply Pat.

          It certainly looks like the re-flashing has finished successfully. I'm going to use objdump tonight to look at the addresses of the sections in the cput32bug s19 file to make sure it's being loaded to the correct address when I load via BDM.

          The BDM cable has been working pretty reliably for the last couple of weeks so I doubt it's anything wrong there.

          I'm assuming since I have a working BDM setup that I should be able to reload a working copy of cpu32bug.... but I'm far from an expert on these things so was hoping someone out there might be able to confirm or deny ;-)

          Cheers,
          James Fitzsimons


          On 9 February 2014 14:21, Pat Tressel <ptressel@...> wrote:
           

          James --

          I think I may have accidentally hosed CPU32Bug on my MRM. 

          I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

          If I connect to the serial port using minicom I get the following:

          CPU32Bug Debugger/Diagnostics - Version  1.00                                  
           (C) Copyright 1991 by Motorola Inc.                       

          CPU32Bug>

          And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

          I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

          Not that it's any comfort, but apparently you're not the first to run into this...the following is from 10 years ago:

          http://list.dprg.org/archive/2004-July/025454.html

          Too bad there's no resolution...

          Can you tell if the re-flashing succeeds?  Is it possible that the modifications mentioned are not compatible?  (They sound benign...)  There's a footnote at the bottom that specifies 19200 baud -- is that what you're using?  Is your BDM cable ok?  (Scraping the bottom of the barrel here...)

          :-(

          -- Pat


        • Mark Castelluccio
          James, CPU32Bug checks the checksum of itself when it starts and reports failures. If it was corrupted, I think you would see that message. Check your power
          Message 4 of 12 , Feb 10, 2014
          • 0 Attachment

            James,

             

            CPU32Bug checks the checksum of itself when it starts and reports failures.  If it was corrupted, I think you would see that message.

             

            Check your power supply.  Make sure you are getting enough power and it is fairly clean.

             

            Do you have an LCD connected?  If so, disconnect it and see if that helps.  The LCD is connected to the data bus, and it may be causing corruption if the cable is too long.

             

            Disconnect everything except power and serial if you can and give that a try.

             

            Mark

             

            From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
            Sent: Saturday, February 08, 2014 4:20 PM
            To: SeattleRobotics@yahoogroups.com; robominds@yahoogroups.com
            Subject: [RoboMinds] MRM trouble!

             

             

            Hi all,

             

            I think I may have accidentally hosed CPU32Bug on my MRM. 

             

            I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

             

            If I connect to the serial port using minicom I get the following:

             

            CPU32Bug Debugger/Diagnostics - Version  1.00                                  

             (C) Copyright 1991 by Motorola Inc.                       

             

            CPU32Bug>

             

            And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

             

            I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

             

            Anyone got any advice?

             

            Thanks!

            James Fitzsimons

          • James Fitzsimons
            Hi Mark, Thanks for your reply. I actually read about the CPU32Bug self check in the manual just the other night so had already had a similar thought. I would
            Message 5 of 12 , Feb 11, 2014
            • 0 Attachment
              Hi Mark,

              Thanks for your reply.

              I actually read about the CPU32Bug self check in the manual just the other night so had already had a similar thought.

              I would have thought the power supply was good, but just to make sure I'll try running it off a battery using the on-board regulator for a comparison.

              I tried as you suggested and disconnected everything apart from the serial cable tonight. (there was only the LCD and BDM pod connected previously).

              Interestingly I got some different results. Powering up the MRM while connected to minicom gave the following output:

              CPU32Bug Debugger/Diagnostics - Version  1.00                                   
               (C) Copyright 1991 by Motorola Inc.                                            
                                                                                              
              CPU32Bug>                                                                       
              Exception: Bus Error                                                            
              PC=000034D4, SR=2710                                                            
              Format/Vector=C008                                                              
              SSW=0225  Fault Addr.=74747470  Data=7C000800  Cur. PC=000034D4  Cnt. Reg.=0008 
              CPU32Bug>                                                                       
              Exception: Bus Error                                                            
              PC=00003CDC, SR=2710                                                            
              Format/Vector=C008                                                              
              SSW=004D  Fault Addr.=00FF6600  Data=00FF66FF  Cur. PC=00003CDC  Cnt. Reg.=0008 
              CPU32Bug>                                                                       
              Exception: F-line                                                               
              PC=0000493C, SR=2700                                                            
              Format/Vector=002C                                                              
              CPU32Bug>                                                                       
              Exception: Illegal Instr.                                                       
              PC=0404BAA2, SR=2700                                                            
              Format/Vector=0010                                                              
              CPU32Bug>                                                                       
              Exception: Illegal Instr.                                                       
              PC=04045A5A, SR=2700                                                            
              Format/Vector=0010                                                              
              CPU32Bug>                                                                       
              Exception: Illegal Instr.                                                       
              PC=000048A4, SR=2700                                                            
              Format/Vector=0010                                                              
              CPU32Bug>                                                                       
              Exception: Illegal Instr.                                                       
              PC=040439A4, SR=2700                                                            
              Format/Vector=0010                                                              
              CPU32Bug>

              It kept printing new messages and the CPU32Bug prompt until it hung.

              I tried again and quickly entered diagnostics mode with the SD command, then ran the self test:

              CPU32Bug Debugger/Diagnostics - Version  1.00                                   
               (C) Copyright 1991 by Motorola Inc.                                            
                                                                                              
              CPU32Bug>sd                                                                     
              CPU32Diag>st                                                                    
              Exception: F-line                                                               
              PC=00010018, SR=2708                                                            
              Format/Vector=002C                                                              
              CPU32Diag>st                                                                    
              E        March Addr. Test.............. Running ---> PASSED                     
              F        Walk a bit Test............... Running ---> PASSED                     
              H        Random Byte Test.............. Running ---> PA                         
              Exception: Unexpected

              It looks like something is causing an interrupt / reset / bus error or something similar?

              I'm well out of my depth now and learning as I go! I keep reading the CPU32Bug manual and see if there is anything more in there that might shed some light on this behaviour.

              Regards,
              James Fitzsimons 



              On 11 February 2014 07:38, Mark Castelluccio <markc@...> wrote:

              James,

               

              CPU32Bug checks the checksum of itself when it starts and reports failures.  If it was corrupted, I think you would see that message.

               

              Check your power supply.  Make sure you are getting enough power and it is fairly clean.

               

              Do you have an LCD connected?  If so, disconnect it and see if that helps.  The LCD is connected to the data bus, and it may be causing corruption if the cable is too long.

               

              Disconnect everything except power and serial if you can and give that a try.

               

              Mark

               

              From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
              Sent: Saturday, February 08, 2014 4:20 PM
              To: SeattleRobotics@yahoogroups.com; robominds@yahoogroups.com
              Subject: [RoboMinds] MRM trouble!

               

               

              Hi all,

               

              I think I may have accidentally hosed CPU32Bug on my MRM. 

               

              I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

               

              If I connect to the serial port using minicom I get the following:

               

              CPU32Bug Debugger/Diagnostics - Version  1.00                                  

               (C) Copyright 1991 by Motorola Inc.                       

               

              CPU32Bug>

               

              And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

               

              I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

               

              Anyone got any advice?

               

              Thanks!

              James Fitzsimons


            • Peter Neubauer
              I wonder if CPU32BUG is auto-starting corrupt software in RAM. Normally, CPU32BUG looks for a signature in RAM at address 0x3000. If the signature is present,
              Message 6 of 12 , Feb 11, 2014
              • 0 Attachment
                I wonder if CPU32BUG is auto-starting corrupt software in RAM.  Normally, CPU32BUG looks for a signature in RAM at address 0x3000.  If the signature is present, CPU32BUG loads the initial SSP and PC registers from RAM immediately following the signature.  It's possible that you have a valid signature but bad software.

                Using CPU32BUG or BDM, what are the four bytes at address 0x3000?  If they're 0xbeefbeef, I suggest changing them to something else and resetting the board.  You could also remove the RAM backup battery for a few seconds to clear RAM.

                -Peter


                On 2/11/2014 1:52 AM, James Fitzsimons wrote:
                 
                Hi Mark,

                Thanks for your reply.

                I actually read about the CPU32Bug self check in the manual just the other night so had already had a similar thought.

                I would have thought the power supply was good, but just to make sure I'll try running it off a battery using the on-board regulator for a comparison.

                I tried as you suggested and disconnected everything apart from the serial cable tonight. (there was only the LCD and BDM pod connected previously).

                Interestingly I got some different results. Powering up the MRM while connected to minicom gave the following output:

                CPU32Bug Debugger/Diagnostics - Version  1.00                                   
                 (C) Copyright 1991 by Motorola Inc.                                            
                                                                                                
                CPU32Bug>                                                                       
                Exception: Bus Error                                                            
                PC=000034D4, SR=2710                                                            
                Format/Vector=C008                                                              
                SSW=0225  Fault Addr.=74747470  Data=7C000800  Cur. PC=000034D4  Cnt. Reg.=0008 
                CPU32Bug>                                                                       
                Exception: Bus Error                                                            
                PC=00003CDC, SR=2710                                                            
                Format/Vector=C008                                                              
                SSW=004D  Fault Addr.=00FF6600  Data=00FF66FF  Cur. PC=00003CDC  Cnt. Reg.=0008 
                CPU32Bug>                                                                       
                Exception: F-line                                                               
                PC=0000493C, SR=2700                                                            
                Format/Vector=002C                                                              
                CPU32Bug>                                                                       
                Exception: Illegal Instr.                                                       
                PC=0404BAA2, SR=2700                                                            
                Format/Vector=0010                                                              
                CPU32Bug>                                                                       
                Exception: Illegal Instr.                                                       
                PC=04045A5A, SR=2700                                                            
                Format/Vector=0010                                                              
                CPU32Bug>                                                                       
                Exception: Illegal Instr.                                                       
                PC=000048A4, SR=2700                                                            
                Format/Vector=0010                                                              
                CPU32Bug>                                                                       
                Exception: Illegal Instr.                                                       
                PC=040439A4, SR=2700                                                            
                Format/Vector=0010                                                              
                CPU32Bug>

                It kept printing new messages and the CPU32Bug prompt until it hung.

                I tried again and quickly entered diagnostics mode with the SD command, then ran the self test:

                CPU32Bug Debugger/Diagnostics - Version  1.00                                   
                 (C) Copyright 1991 by Motorola Inc.                                            
                                                                                                
                CPU32Bug>sd                                                                     
                CPU32Diag>st                                                                    
                Exception: F-line                                                               
                PC=00010018, SR=2708                                                            
                Format/Vector=002C                                                              
                CPU32Diag>st                                                                    
                E        March Addr. Test.............. Running ---> PASSED                     
                F        Walk a bit Test............... Running ---> PASSED                     
                H        Random Byte Test.............. Running ---> PA                         
                Exception: Unexpected

                It looks like something is causing an interrupt / reset / bus error or something similar?

                I'm well out of my depth now and learning as I go! I keep reading the CPU32Bug manual and see if there is anything more in there that might shed some light on this behaviour.

                Regards,
                James Fitzsimons 



                On 11 February 2014 07:38, Mark Castelluccio <markc@...> wrote:

                James,

                 

                CPU32Bug checks the checksum of itself when it starts and reports failures.  If it was corrupted, I think you would see that message.

                 

                Check your power supply.  Make sure you are getting enough power and it is fairly clean.

                 

                Do you have an LCD connected?  If so, disconnect it and see if that helps.  The LCD is connected to the data bus, and it may be causing corruption if the cable is too long.

                 

                Disconnect everything except power and serial if you can and give that a try.

                 

                Mark

                 

                From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
                Sent: Saturday, February 08, 2014 4:20 PM
                To: SeattleRobotics@yahoogroups.com; robominds@yahoogroups.com
                Subject: [RoboMinds] MRM trouble!

                 

                 

                Hi all,

                 

                I think I may have accidentally hosed CPU32Bug on my MRM. 

                 

                I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

                 

                If I connect to the serial port using minicom I get the following:

                 

                CPU32Bug Debugger/Diagnostics - Version  1.00                                  

                 (C) Copyright 1991 by Motorola Inc.                       

                 

                CPU32Bug>

                 

                And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

                 

                I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

                 

                Anyone got any advice?

                 

                Thanks!

                James Fitzsimons



              • Mark Castelluccio
                I think Peter s suggestion is a good one. I modified the first few bytes at 0x3000 with a signature that would indicate a program is present and reset. I
                Message 7 of 12 , Feb 11, 2014
                • 0 Attachment

                  I think Peter’s suggestion is a good one.  I modified the first few bytes at 0x3000 with a signature that would indicate a program is present and reset.  I modified with:

                   

                  CPU32Bug>mm 3000

                  00003000 BEEF? beef

                  00003002 BEEF? beef

                  00003004 0007? 0000

                  00003006 7455? 7ffc

                  00003008 055F? 0000

                  0000300A D011? 3010

                  0000300C 7545? 0000

                  0000300E D57F? 0000

                  00003010 3155? .

                  CPU32Bug>

                   

                  When I reset, I got:

                   

                  CPU32Bug Debugger/Diagnostics - Version  1.00                                 

                   (C) Copyright 1991 by Motorola Inc.                      

                   

                  Booting from address $3010

                   

                  Exception: Address Error

                  Format/Vector=C00C

                  SSW=0215  Fault Addr.=0000546D  Data=00000008  Cur. PC=00003014  Cnt. Reg.=0001

                  PC   =00003014 SR   =2700=TR:OFF_S_7_.....   VBR  =00000000

                  SFC  =5=SD     DFC  =5=SD     USP  =0000FC00 SSP* =00007FE4

                  D0   =00000000 D1   =00000000 D2   =00000000 D3   =00000000

                  D4   =00000000 D5   =00000000 D6   =00000000 D7   =00000000

                  A0   =00000000 A1   =00000000 A2   =00000000 A3   =00000000

                  A4   =00000000 A5   =00000000 A6   =00000000 A7   =00007FE4

                  00003014 51775DC5           SUBQ.W      #$8,([$0.N,ZA7],ZD5.L*4,$0.N)

                  CPU32Bug>

                   

                  So, clear the ram using CPU32Bug if you can, or using BDM, or by removing the battery with power removed.

                   

                  Now one thing I do notice that does not support this theory is I get the message “Booting from address $3010” when I boot and I do not get the CPU32Bug prompt until after the error.

                   

                  Mark

                   

                  From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of Peter Neubauer
                  Sent: Tuesday, February 11, 2014 8:55 AM
                  To: robominds@yahoogroups.com
                  Cc: SeattleRobotics@yahoogroups.com
                  Subject: Re: [RoboMinds] MRM trouble!

                   

                   

                  I wonder if CPU32BUG is auto-starting corrupt software in RAM.  Normally, CPU32BUG looks for a signature in RAM at address 0x3000.  If the signature is present, CPU32BUG loads the initial SSP and PC registers from RAM immediately following the signature.  It's possible that you have a valid signature but bad software.

                  Using CPU32BUG or BDM, what are the four bytes at address 0x3000?  If they're 0xbeefbeef, I suggest changing them to something else and resetting the board.  You could also remove the RAM backup battery for a few seconds to clear RAM.

                  -Peter


                  On 2/11/2014 1:52 AM, James Fitzsimons wrote:

                   

                  Hi Mark,

                   

                  Thanks for your reply.

                   

                  I actually read about the CPU32Bug self check in the manual just the other night so had already had a similar thought.

                   

                  I would have thought the power supply was good, but just to make sure I'll try running it off a battery using the on-board regulator for a comparison.

                   

                  I tried as you suggested and disconnected everything apart from the serial cable tonight. (there was only the LCD and BDM pod connected previously).

                   

                  Interestingly I got some different results. Powering up the MRM while connected to minicom gave the following output:

                   

                  CPU32Bug Debugger/Diagnostics - Version  1.00                                   

                   (C) Copyright 1991 by Motorola Inc.                                            

                                                                                                  

                  CPU32Bug>                                                                       

                  Exception: Bus Error                                                            

                  PC=000034D4, SR=2710                                                            

                  Format/Vector=C008                                                              

                  SSW=0225  Fault Addr.=74747470  Data=7C000800  Cur. PC=000034D4  Cnt. Reg.=0008 

                  CPU32Bug>                                                                       

                  Exception: Bus Error                                                            

                  PC=00003CDC, SR=2710                                                            

                  Format/Vector=C008                                                              

                  SSW=004D  Fault Addr.=00FF6600  Data=00FF66FF  Cur. PC=00003CDC  Cnt. Reg.=0008 

                  CPU32Bug>                                                                       

                  Exception: F-line                                                               

                  PC=0000493C, SR=2700                                                            

                  Format/Vector=002C                                                              

                  CPU32Bug>                                                                       

                  Exception: Illegal Instr.                                                       

                  PC=0404BAA2, SR=2700                                                            

                  Format/Vector=0010                                                              

                  CPU32Bug>                                                                       

                  Exception: Illegal Instr.                                                       

                  PC=04045A5A, SR=2700                                                            

                  Format/Vector=0010                                                              

                  CPU32Bug>                                                                       

                  Exception: Illegal Instr.                                                       

                  PC=000048A4, SR=2700                                                            

                  Format/Vector=0010                                                              

                  CPU32Bug>                                                                       

                  Exception: Illegal Instr.                                                       

                  PC=040439A4, SR=2700                                                            

                  Format/Vector=0010                                                              

                  CPU32Bug>

                   

                  It kept printing new messages and the CPU32Bug prompt until it hung.

                   

                  I tried again and quickly entered diagnostics mode with the SD command, then ran the self test:

                   

                  CPU32Bug Debugger/Diagnostics - Version  1.00                                   

                   (C) Copyright 1991 by Motorola Inc.                                            

                                                                                                  

                  CPU32Bug>sd                                                                     

                  CPU32Diag>st                                                                    

                  Exception: F-line                                                               

                  PC=00010018, SR=2708                                                            

                  Format/Vector=002C                                                              

                  CPU32Diag>st                                                                    

                  E        March Addr. Test.............. Running ---> PASSED                     

                  F        Walk a bit Test............... Running ---> PASSED                     

                  H        Random Byte Test.............. Running ---> PA                         

                  Exception: Unexpected

                   

                  It looks like something is causing an interrupt / reset / bus error or something similar?

                   

                  I'm well out of my depth now and learning as I go! I keep reading the CPU32Bug manual and see if there is anything more in there that might shed some light on this behaviour.

                   

                  Regards,

                  James Fitzsimons 

                   

                   

                  On 11 February 2014 07:38, Mark Castelluccio <markc@...> wrote:

                  James,

                   

                  CPU32Bug checks the checksum of itself when it starts and reports failures.  If it was corrupted, I think you would see that message.

                   

                  Check your power supply.  Make sure you are getting enough power and it is fairly clean.

                   

                  Do you have an LCD connected?  If so, disconnect it and see if that helps.  The LCD is connected to the data bus, and it may be causing corruption if the cable is too long.

                   

                  Disconnect everything except power and serial if you can and give that a try.

                   

                  Mark

                   

                  From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
                  Sent: Saturday, February 08, 2014 4:20 PM
                  To: SeattleRobotics@yahoogroups.com; robominds@yahoogroups.com
                  Subject: [RoboMinds] MRM trouble!

                   

                   

                  Hi all,

                   

                  I think I may have accidentally hosed CPU32Bug on my MRM. 

                   

                  I've been trying to get RTEMS running out of ROM on my MRM and have been having a lot of trouble with linker scripts. After doing a ton of reading I think I'm getting a better handle on it, but I think that during my experimentation I may have overwritten part of CPU32Bug as it no longer responds at the prompt or starts programs loaded into the MRM.

                   

                  If I connect to the serial port using minicom I get the following:

                   

                  CPU32Bug Debugger/Diagnostics - Version  1.00                                  

                   (C) Copyright 1991 by Motorola Inc.                       

                   

                  CPU32Bug>

                   

                  And then it hangs. I've tried this on two different computers to check it's not a dodgy serial port problem.

                   

                  I've tried loading mcbug.s19 from Marks website (http://robominds.com/minirobomind_sw.htm) using the bdm, but no luck.

                   

                  Anyone got any advice?

                   

                  Thanks!

                  James Fitzsimons

                   

                   

                • dpa_io
                  I have seen something similar that was related to the TPU pins. As I remember, I once had to add pullups to a couple of pins to get an MRM board to boot
                  Message 8 of 12 , Feb 12, 2014
                  • 0 Attachment
                    I have seen something similar that was related to the TPU pins.   As I remember, I once had to add pullups to a couple of pins to get an MRM board to boot properly.  May not be your problem here, but the output was similar.    Also, for some reason, the boards will not boot if anything is connected to PortF pin 1.   Mark, is that right?

                    dpa
                  • James Fitzsimons
                    Hi all, I d like to thank everyone for taking the time to reply and help me out with this! Dpa hit the nail on the head - it looks like it was the TPU pins.
                    Message 9 of 12 , Feb 13, 2014
                    • 0 Attachment
                      Hi all,

                      I'd like to thank everyone for taking the time to reply and help me out with this!

                      Dpa hit the nail on the head - it looks like it was the TPU pins. When Mark suggested I disconnect everything I did... or at least I thought I did. I have a connection from the TPU to my h-bridge and I had unplugged the h-bridge end, but I left the cable plugged in. It looks like even just having the cable plugged in and not connected to anything was enough to cause this behaviour.

                      Once I unplugged the cable from the TPU the MRM was rock solid and CPU32Bug behaved as expected. I used the sd command to switch to diagnostics mode, ran the self test and everything passed. I then loaded the MRMTEST.S19 from Mark's website and ran that. Interestingly if I try to select either the 16Mhz or 25Mhz clock options the MRM will reboot, however if I just hit enter at that prompt and default to the 8.389 Mhz clock it will run the whole test program fine.

                      I'm hoping that's an anomaly and everything is now fine. 

                      Thanks again for your help all - learning lots here!

                      Cheers,
                      James Fitzsimons 


                      On 13 February 2014 05:13, <davida@...> wrote:
                       

                      I have seen something similar that was related to the TPU pins.   As I remember, I once had to add pullups to a couple of pins to get an MRM board to boot properly.  May not be your problem here, but the output was similar.    Also, for some reason, the boards will not boot if anything is connected to PortF pin 1.   Mark, is that right?

                      dpa


                    • dpa_io
                      Cool. For what it s worth, nBot in it s current enlightenment has 47k pull ups on all TPU pins, used and unused, except for the two pins that driver the
                      Message 10 of 12 , Feb 13, 2014
                      • 0 Attachment
                        Cool. 

                        For what it's worth, nBot in it's current enlightenment has 47k pull ups on all TPU pins, used and unused, except for the two pins that driver the PING))) sensors, which have pull-downs.  Those two pins must act both as outputs, to initialize the ping, and inputs, to measure the timing of the returned pulse. 

                        From the 68332 manual, it appears the problem is that noise on the TPU lines, if they are left floating, can produce spurious interrupts.  Real interrupts must stay up long enough for the  IARB line to be asserted, and if not it can "cause the CPU to crash."  Which I guess is what we're seeing.

                        As an aside, I don't have an RTEM implementation, but  I rolled my own light-weight multitasking reatlime executive for the MRM which is what is used on nBot and jBot, and which I'd be happy to share if that would be useful.

                        -dpa
                      • James Fitzsimons
                        Hi dpa, I d be interested in how you added the 47k pullups. Did you retro fit them directly to the MRM or are they on a separate board? I plan to keep
                        Message 11 of 12 , Feb 14, 2014
                        • 0 Attachment
                          Hi dpa,

                          I'd be interested in how you added the 47k pullups. Did you retro fit them directly to the MRM or are they on a separate board? 

                          I plan to keep investigating RTEMS a bit further yet, but I'd would be very interested to see your realtime executive if you're happy to share. It's always a great learning opportunity to look at how someone else has solved a problem or implemented something.

                          Hopefully now that I'm past that little distraction I can start making some actual progress on writing some software!

                          Cheers,
                          James Fitzsimons



                          On 14 February 2014 08:38, <davida@...> wrote:
                           

                          Cool. 

                          For what it's worth, nBot in it's current enlightenment has 47k pull ups on all TPU pins, used and unused, except for the two pins that driver the PING))) sensors, which have pull-downs.  Those two pins must act both as outputs, to initialize the ping, and inputs, to measure the timing of the returned pulse. 

                          From the 68332 manual, it appears the problem is that noise on the TPU lines, if they are left floating, can produce spurious interrupts.  Real interrupts must stay up long enough for the  IARB line to be asserted, and if not it can "cause the CPU to crash."  Which I guess is what we're seeing.

                          As an aside, I don't have an RTEM implementation, but  I rolled my own light-weight multitasking reatlime executive for the MRM which is what is used on nBot and jBot, and which I'd be happy to share if that would be useful.

                          -dpa


                        • dpa_io
                          James, each device that the MRM TPU pins are connected to, H-Bridge, shaft encoders, ping and IR sensors, etc, has pullups/downs on the device itself. For
                          Message 12 of 12 , Feb 14, 2014
                          • 0 Attachment
                            James,  each device that the MRM TPU pins are connected to, H-Bridge, shaft encoders, ping and IR sensors, etc, has pullups/downs on the device itself.  For the unused pins (only 4) I made headers that plug directly onto the MRM board, likes this:

                            <http://www.geology.smu.edu/dpa-www/robo/pulldown.jpg>

                            I'll send you a tarball of the RTOS offlist for you to play with.

                            cheers
                            dpa
                          Your message has been successfully submitted and would be delivered to recipients shortly.