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

68332 can't run program twice

Expand Messages
  • James Fitzsimons
    Hi all, I m still trying to get RTEMS running on my MRM and have hit an odd problem. I ve developed an RTEMS hello world that simply prints a message to the
    Message 1 of 8 , Feb 25, 2014
    • 0 Attachment
      Hi all,

      I'm still trying to get RTEMS running on my MRM and have hit an odd problem. I've developed an RTEMS hello world that simply prints a message to the console. I'm downloading the program to RAM, and at the moment it doesn't have the 0xBEEFBEEF magic code to enable the CPU32Bug auto run feature.

      After I download the program using the BDM cable the program runs as expected and prints "hello RTEMS world" to the console over and over. However, if I stop the program by resetting the MRM I am unable to run it again without going through the download process each time. If I try to run the program from the CPU32Bug prompt I get this:

      CPU32Bug>go 10000                                                               
      Effective address: 00010000                                                     
      \����fu���Ѯ�i��ӊ�:Q����lîÍÚӎX���EE�Ӛ�������Z���������M����;��/Í�]����ѽQ

      I've inspected the registers immediately after download using the CPU32Bug RD command, but even if I set them up the same way using the RS (register set) command I get the same result.

      Has anyone encountered anything like this before?

      Cheers,
      James Fitzsimons
    • Mark Castelluccio
      How do you run the program after downloading using BDM? Mark From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
      Message 2 of 8 , Feb 25, 2014
      • 0 Attachment

         

        How do you run the program after downloading using BDM?

         

        Mark

         

        From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
        Sent: Tuesday, February 25, 2014 1:32 AM
        To: SeattleRobotics@yahoogroups.com; robominds@yahoogroups.com
        Subject: [RoboMinds] 68332 can't run program twice

         

         

        Hi all,

         

        I'm still trying to get RTEMS running on my MRM and have hit an odd problem. I've developed an RTEMS hello world that simply prints a message to the console. I'm downloading the program to RAM, and at the moment it doesn't have the 0xBEEFBEEF magic code to enable the CPU32Bug auto run feature.

         

        After I download the program using the BDM cable the program runs as expected and prints "hello RTEMS world" to the console over and over. However, if I stop the program by resetting the MRM I am unable to run it again without going through the download process each time. If I try to run the program from the CPU32Bug prompt I get this:

         

        CPU32Bug>go 10000                                                               

        Effective address: 00010000                                                     

        \����fu���Ѯi��ӊ:Q����lîÍÚӎX���EEӚ�������Z���������M����;��/‑Í]���­ѽQ

         

        I've inspected the registers immediately after download using the CPU32Bug RD command, but even if I set them up the same way using the RS (register set) command I get the same result.

         

        Has anyone encountered anything like this before?

         

        Cheers,

        James Fitzsimons

      • Peter Neubauer
        The compiler emits an initialized data segment (named .data ). Depending on your linker script and CRT startup code, it s possible that this data isn t
        Message 3 of 8 , Feb 25, 2014
        • 0 Attachment
          The compiler emits an "initialized data" segment (named ".data").  Depending on your linker script and CRT startup code, it's possible that this data isn't getting reinitialized on restart.
              -Peter

          On 2/25/2014 1:31 AM, James Fitzsimons wrote:
           
          Hi all,

          I'm still trying to get RTEMS running on my MRM and have hit an odd problem. I've developed an RTEMS hello world that simply prints a message to the console. I'm downloading the program to RAM, and at the moment it doesn't have the 0xBEEFBEEF magic code to enable the CPU32Bug auto run feature.

          After I download the program using the BDM cable the program runs as expected and prints "hello RTEMS world" to the console over and over. However, if I stop the program by resetting the MRM I am unable to run it again without going through the download process each time. If I try to run the program from the CPU32Bug prompt I get this:

          CPU32Bug>go 10000                                                               
          Effective address: 00010000                                                     
          \����fu���Ѯ�i��ӊ�:Q����lîÍÚӎX���EE�Ӛ�������Z���������M����;��/Í�]����ѽQ

          I've inspected the registers immediately after download using the CPU32Bug RD command, but even if I set them up the same way using the RS (register set) command I get the same result.

          Has anyone encountered anything like this before?

          Cheers,
          James Fitzsimons

        • James Fitzsimons
          Hi Mark, When I download using the BDM it automatically runs the program once it has completed downloading. If I download using CPU32Bug I use a command like
          Message 4 of 8 , Feb 26, 2014
          • 0 Attachment
            Hi Mark,

            When I download using the BDM it automatically runs the program once it has completed downloading. If I download using CPU32Bug I use a command like "go $10000" to run. In both cases the result is the same, the program runs successfully once, then fails to run a second time.

            Cheers,
            James


            On 26 February 2014 16:55, Mark Castelluccio <markc@...> wrote:

             

            How do you run the program after downloading using BDM?

             

            Mark

             

            From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
            Sent: Tuesday, February 25, 2014 1:32 AM
            To: SeattleRobotics@yahoogroups.com; robominds@yahoogroups.com
            Subject: [RoboMinds] 68332 can't run program twice

             

             

            Hi all,

             

            I'm still trying to get RTEMS running on my MRM and have hit an odd problem. I've developed an RTEMS hello world that simply prints a message to the console. I'm downloading the program to RAM, and at the moment it doesn't have the 0xBEEFBEEF magic code to enable the CPU32Bug auto run feature.

             

            After I download the program using the BDM cable the program runs as expected and prints "hello RTEMS world" to the console over and over. However, if I stop the program by resetting the MRM I am unable to run it again without going through the download process each time. If I try to run the program from the CPU32Bug prompt I get this:

             

            CPU32Bug>go 10000                                                               

            Effective address: 00010000                                                     

            \����fu���Ѯi��ӊ:Q����lîÍÚӎX���EEӚ�������Z���������M����;��/‑Í]���­ѽQ

             

            I've inspected the registers immediately after download using the CPU32Bug RD command, but even if I set them up the same way using the RS (register set) command I get the same result.

             

            Has anyone encountered anything like this before?

             

            Cheers,

            James Fitzsimons


          • James Fitzsimons
            Hi Peter, That was a great thought! I think I might be getting somewhere now. To test this theory I used the -M option of the gnu linker to create a map file
            Message 5 of 8 , Feb 26, 2014
            • 0 Attachment
              Hi Peter,

              That was a great thought! I think I might be getting somewhere now.

              To test this theory I used the -M option of the gnu linker to create a map file and see what the address of the .data section was. I then used the cpu32bug MD (memory display) command to dump that memory out before and after running the program. I could see by comparing the two files that the contents of the .data section were definitely different after the first run. The .data section should be read/write, so this isn't entirely unexpected, but it was intriguing.

              Next I reloaded the program then made a copy of the vanilla .data section in another unused area of memory using the cpu32bug BM (block of memory move) command. I ran the program, then copied the original .data section back over the now modified .data section. Tried re-running the program and Et voila! It worked.

              So! I'm beginning to think this RTEMS BSP for the MRM can never have worked in it's current state. If I was running this out of ROM I wouldn't have this issue as the crt0 code would be copying a fresh version of the .data section into RAM each time, however I am running out of RAM so that is not happening. Does it seem strange that you would need to have a second copy of .data even when running out of RAM though?

              Thanks all - I am now one step closer to understanding this problem.

              Cheers,
              James 


              On 26 February 2014 17:13, Peter Neubauer <pneubauer@...> wrote:
              The compiler emits an "initialized data" segment (named ".data").  Depending on your linker script and CRT startup code, it's possible that this data isn't getting reinitialized on restart.
                  -Peter


              On 2/25/2014 1:31 AM, James Fitzsimons wrote:
               
              Hi all,

              I'm still trying to get RTEMS running on my MRM and have hit an odd problem. I've developed an RTEMS hello world that simply prints a message to the console. I'm downloading the program to RAM, and at the moment it doesn't have the 0xBEEFBEEF magic code to enable the CPU32Bug auto run feature.

              After I download the program using the BDM cable the program runs as expected and prints "hello RTEMS world" to the console over and over. However, if I stop the program by resetting the MRM I am unable to run it again without going through the download process each time. If I try to run the program from the CPU32Bug prompt I get this:

              CPU32Bug>go 10000                                                               
              Effective address: 00010000                                                     
              \����f u���Ѯ�i��ӊ �:Q����lîÍÚӎX���EE�Ӛ�������Z���������M����; ��/ Í�]��� �ѽQ

              I've inspected the registers immediately after download using the CPU32Bug RD command, but even if I set them up the same way using the RS (register set) command I get the same result.

              Has anyone encountered anything like this before?

              Cheers,
              James Fitzsimons


            • Dave Hylands
              Hey James, On Wed, Feb 26, 2014 at 1:49 AM, James Fitzsimons wrote: ... worked in it s current state. If I was running this out
              Message 6 of 8 , Feb 26, 2014
              • 0 Attachment
                Hey James,

                On Wed, Feb 26, 2014 at 1:49 AM, James Fitzsimons <james.fitzsimons@...> wrote:
                ...snip...

                > So! I'm beginning to think this RTEMS BSP for the MRM can never have worked in it's current state. If I was running this out of ROM I wouldn't have this issue as the crt0 code would be copying a fresh version of the .data section into RAM each time, however I am running out of RAM so that is not happening. Does it seem strange that you would need to have a second copy of .data even when running out of RAM though?
                >
                > Thanks all - I am now one step closer to understanding this problem.

                This isn't necessarily surprising. Many programs won't work if you run them out of RAM without reinitializing .data.

                If your code did something like this:

                bool already_initalized = false;  // Declared as a global

                if (already_initialized) {
                    return;
                }
                already_initialized = true;

                Then the second time that you ran that function already_initialized would be set to true and it wouldn't do the initialization, which could cause all kinds of havoc. Any globals containing pointers into the heap would be invalid since the heap would be reinitialized, but the data section would still have stale pointers.


                --
                Dave Hylands
                Shuswap, BC, Canada
                http://www.davehylands.com
              • James Fitzsimons
                Hi Dave, Thanks for your reply. I should have realised that of course! It s a combination of being pretty rusty when it comes to embedded development and being
                Message 7 of 8 , Mar 2, 2014
                • 0 Attachment
                  Hi Dave,

                  Thanks for your reply. 

                  I should have realised that of course! It's a combination of being pretty rusty when it comes to embedded development and being blinded by the fact that I keep assuming this RTEMS BSP was in a working state.

                  I'm now taking nothing for granted and am working through it all once step at a time.

                  So far I have found several errors in the linker file and the C start up code. I'm now debugging by "walking" some code that switches the green LED on the MRM on through the start up process. 

                  Interestingly the program that was running out of RAM (albeit only once) doesn't run out of ROM, so I'm suspect about either the linker script, or some more of the BSP startup code.

                  It's a slow process but I really don't want to let this one beat me now!

                  Cheers,
                  James


                  On 27 February 2014 04:52, Dave Hylands <dhylands@...> wrote:
                  Hey James,

                  On Wed, Feb 26, 2014 at 1:49 AM, James Fitzsimons <james.fitzsimons@...> wrote:
                  ...snip...


                  > So! I'm beginning to think this RTEMS BSP for the MRM can never have worked in it's current state. If I was running this out of ROM I wouldn't have this issue as the crt0 code would be copying a fresh version of the .data section into RAM each time, however I am running out of RAM so that is not happening. Does it seem strange that you would need to have a second copy of .data even when running out of RAM though?
                  >
                  > Thanks all - I am now one step closer to understanding this problem.

                  This isn't necessarily surprising. Many programs won't work if you run them out of RAM without reinitializing .data.

                  If your code did something like this:

                  bool already_initalized = false;  // Declared as a global

                  if (already_initialized) {
                      return;
                  }
                  already_initialized = true;

                  Then the second time that you ran that function already_initialized would be set to true and it wouldn't do the initialization, which could cause all kinds of havoc. Any globals containing pointers into the heap would be invalid since the heap would be reinitialized, but the data section would still have stale pointers.


                  --
                  Dave Hylands
                  Shuswap, BC, Canada
                  http://www.davehylands.com

                • James Fitzsimons
                  I thought I d post a quick follow up to my last update. I managed to crack it tonight and now have the RTEMS RTOS running on my MRM! I ve had to fix a number
                  Message 8 of 8 , Mar 10, 2014
                  • 0 Attachment
                    I thought I'd post a quick follow up to my last update. I managed to crack it tonight and now have the RTEMS RTOS running on my MRM!

                    I've had to fix a number of issues with the mrm332 bsp, but it now works and runs out of ROM with the CPU32Bug auto run feature as well.

                    I've got to clean up my changes a bit, but I should have a working patch for the 4.10.2 version of RTEMS shortly and I'll post it to the list for anyone that's interested.

                    So, now that the I have a working RTOS I'll have to start writing some application code ;-)

                    Cheers for all your help guys!
                    James Fitzsimons


                    On 2 March 2014 22:37, James Fitzsimons <james.fitzsimons@...> wrote:
                    Hi Dave,

                    Thanks for your reply. 

                    I should have realised that of course! It's a combination of being pretty rusty when it comes to embedded development and being blinded by the fact that I keep assuming this RTEMS BSP was in a working state.

                    I'm now taking nothing for granted and am working through it all once step at a time.

                    So far I have found several errors in the linker file and the C start up code. I'm now debugging by "walking" some code that switches the green LED on the MRM on through the start up process. 

                    Interestingly the program that was running out of RAM (albeit only once) doesn't run out of ROM, so I'm suspect about either the linker script, or some more of the BSP startup code.

                    It's a slow process but I really don't want to let this one beat me now!

                    Cheers,
                    James


                    On 27 February 2014 04:52, Dave Hylands <dhylands@...> wrote:
                    Hey James,

                    On Wed, Feb 26, 2014 at 1:49 AM, James Fitzsimons <james.fitzsimons@...> wrote:
                    ...snip...


                    > So! I'm beginning to think this RTEMS BSP for the MRM can never have worked in it's current state. If I was running this out of ROM I wouldn't have this issue as the crt0 code would be copying a fresh version of the .data section into RAM each time, however I am running out of RAM so that is not happening. Does it seem strange that you would need to have a second copy of .data even when running out of RAM though?
                    >
                    > Thanks all - I am now one step closer to understanding this problem.

                    This isn't necessarily surprising. Many programs won't work if you run them out of RAM without reinitializing .data.

                    If your code did something like this:

                    bool already_initalized = false;  // Declared as a global

                    if (already_initialized) {
                        return;
                    }
                    already_initialized = true;

                    Then the second time that you ran that function already_initialized would be set to true and it wouldn't do the initialization, which could cause all kinds of havoc. Any globals containing pointers into the heap would be invalid since the heap would be reinitialized, but the data section would still have stale pointers.


                    --
                    Dave Hylands
                    Shuswap, BC, Canada
                    http://www.davehylands.com


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