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

Difficulties with GDB and 9S12C128

Expand Messages
  • Nigel
    I have a working program that I have been developing using gcc on a windows machine, and debugging using NoICE with a Tech Arts uBDM12SX, a P & E USN
    Message 1 of 8 , Jan 2, 2011
    • 0 Attachment
      I have a working program that I have been developing using gcc on a windows machine, and debugging using NoICE with a Tech Arts uBDM12SX, a P & E USN Multilink, and a TBDML. So far so good, all of the above allow me to compile and load no problem.

      I decided to switch to linux to be compatible with some people who will be taking the program further (I am writing only the hardware interface routines since I designed the hardware I am using).

      So I have gcc running on SuSE 11.2 64 bit, no problem. I can compile to s record and the s record compares well to the original I had on the pc except for a few address changes made after I left the PC.

      when I try to run m6811-elf-gdb I get varying results. If I try to load the target program after I start gdb, I get a seg fault every time.

      If I mention the target program elf file on the command line, it sucessfully loads the elf file and I can list source code and generally run the commands to examine it.

      If I connect a tech arts uBDM12Sx to the target and issue the target dbug /dev/ttyUSB0, I can see comm lights on the dbug pod and I get a connected message. After this point I can examine memory in the target, I know it is coming from the target because I can see teh TX/RX lights blinkin gon the debug ppod.

      The problem is, I cannot see anywhere how to load my program into flash. If I move back to the windows box I can load it using NoICE on the same debug pod, so I lknow my hardware is working!

      Am I missing something? I have searched through the man pages and on the internet and I can find no mention.

      Any help very much appreciated.

      regards,

      Nigel Johnson
      ve3id
    • jsmcortina
      ... I m afraid I cannot offer any positive help here, but I m interested to see how you get on. I use gcc for S12 extensively but pretty much never use gdb. In
      Message 2 of 8 , Jan 4, 2011
      • 0 Attachment
        --- In gnu-m68hc11@yahoogroups.com, "Nigel" <ve3id@...> wrote:
        >
        > I have a working program that I have been developing using gcc on a windows machine, and debugging using NoICE with a Tech Arts uBDM12SX, a P & E USN Multilink, and a TBDML. So far so good, all of the above allow me to compile and load no problem.
        >

        I'm afraid I cannot offer any positive help here, but I'm interested to see how you get on.

        I use gcc for S12 extensively but pretty much never use gdb.

        In the rare times I need to use BDM I use my Windows computer and use CodeWarrior HIWAVE with the P&E USB BDM. However, for inexpicable reasons that combined with my target is unbelievably unreliable.
        BDM sessions will usually abort for no reason. Sometimes they work fine for 12 hrs other times it blows up immediately after half a second. Horrible.

        A long while back a friend of mine did some work on a Linux driver for the USB BDM with limited success. He sort of got it working, but it was no more stable than the Windows version and the interface was clunky.

        For code building, if your code speed matters, consider using the gcc build I posted on here a few months ago as the 32/32 divide is massively faster for S12 and S12X targets. However, I don't include gdb in there as I don't use it.

        I would prefer to keep all my build and debug under Linux, so perhaps I'll revisit the ddd/gdb/P&E USB-BDM work again.
        If anyone fancies working on that code to finish it off, I'm sure my friend would release the source. Please ask me.

        James
      • VE3ID
        I d be glad to share anything I find, but right now there does not seem to be a command to load the s record file into flash memory. I have taken the file I
        Message 3 of 8 , Jan 4, 2011
        • 0 Attachment
          I'd be glad to share anything I find, but right now there does not seem to be a command to load the s record file into flash memory.  I have taken the file I had, in S2 record format and tried it, and even sending it with minicom I get a "S-record out of range" error using the tech arts debug pod.  I tried converting the elf file to an s1 file using

          m6811-elf-objcopy  mcx12.elf -O srec mcx12a.s19

          and it gives an s19 file that I recognise, addresses correct, but it seems to take it (without echoing asterisks or returning to the prompt after loading) but nothing happens to the internal flash.

          (The original elf file, and the s2 record file were both flashable

          Incidentally, if I try to manually send the lines of the original S2 file it takes the first line (the header), echoes an asterisk, but chokes on the second line.

          Does anybody have a link to a full 68hc12 style version of the gdb?  The one at

          http://www.gnu.org/software/m68hc11/m68hc11_gdb.html

          Is only one page and just shows you how to use the sim.

          To re-iterate, I can get access to memory of the 9S12 using m6811-elf-gdb and target dbug /dev/ttyS0, but I can't figure out how to get my program loaded into flash.

          regards,
          Nigel





          On 04/01/11 09:58, jsmcortina wrote:
           



          --- In gnu-m68hc11@yahoogroups.com, "Nigel" <ve3id@...> wrote:
          >
          > I have a working program that I have been developing using gcc on a windows machine, and debugging using NoICE with a Tech Arts uBDM12SX, a P & E USN Multilink, and a TBDML. So far so good, all of the above allow me to compile and load no problem.
          >

          I'm afraid I cannot offer any positive help here, but I'm interested to see how you get on.

          I use gcc for S12 extensively but pretty much never use gdb.

          In the rare times I need to use BDM I use my Windows computer and use CodeWarrior HIWAVE with the P&E USB BDM. However, for inexpicable reasons that combined with my target is unbelievably unreliable.
          BDM sessions will usually abort for no reason. Sometimes they work fine for 12 hrs other times it blows up immediately after half a second. Horrible.

          A long while back a friend of mine did some work on a Linux driver for the USB BDM with limited success. He sort of got it working, but it was no more stable than the Windows version and the interface was clunky.

          For code building, if your code speed matters, consider using the gcc build I posted on here a few months ago as the 32/32 divide is massively faster for S12 and S12X targets. However, I don't include gdb in there as I don't use it.

          I would prefer to keep all my build and debug under Linux, so perhaps I'll revisit the ddd/gdb/P&E USB-BDM work again.
          If anyone fancies working on that code to finish it off, I'm sure my friend would release the source. Please ask me.

          James



        • jsmcortina
          As far as I recall, I thought the .elf file is what you needed to load to device memory? (In my application we use a serial bootloader/monitor derived from the
          Message 4 of 8 , Jan 4, 2011
          • 0 Attachment
            As far as I recall, I thought the .elf file is what you needed to load to device memory?

            (In my application we use a serial bootloader/monitor derived from the Freescale application note and load the application code by serial with that.)

            James
          • ve3id
            Yes, it is. It has all the debug info and binary image, but there must be another step to get it to do the flash. I am familiar with the serial loader,
            Message 5 of 8 , Jan 5, 2011
            • 0 Attachment
              Yes, it is.  It has all the debug info and binary image, but there must be another step to get it to do the flash.  I am familiar with the serial loader, unfortunately when I laid out the board I let the PLL circuit get too close to some noise and it doesn't work.  We are moving away from using the serial monitor here at the college whjere I teach since the students have so many different serial dongles!

              I can load it and list the source code from within gdb, I can exmaine memory in the chip, and I can step through a program that I load into flash using windoze!


              cheers,
              Nigel


              On 11-01-04 21:19, jsmcortina wrote:
               

              As far as I recall, I thought the .elf file is what you needed to load to device memory?

              (In my application we use a serial bootloader/monitor derived from the Freescale application note and load the application code by serial with that.)

              James





            • Mike McCarty
              ve3id wrote: [...] ... Can you get it to load into RAM? Perhaps GDB just doesn t know how to program FLASH. Different chips have different sector sizes and all
              Message 6 of 8 , Jan 5, 2011
              • 0 Attachment
                ve3id wrote:

                [...]

                > I can load it and list the source code from within gdb, I can exmaine
                > memory in the chip, and I can step through a program that I load into
                > flash using windoze!

                Can you get it to load into RAM? Perhaps GDB just doesn't know
                how to program FLASH. Different chips have different sector
                sizes and all that, so maybe that's the failure. The GDB
                team didn't want to build a bunch of knowledge about chips
                into the debugger. GDB doesn't buffer up a whole sector, so
                after each byte (or word, or whatever) it puts there, the
                FLASH starts an erase, and then comes along some more data
                which don't make it.

                Mike
                --
                p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
                Oppose globalization and One World Governments like the UN.
                This message made from 100% recycled bits.
                You have found the bank of Larn.
                I speak only for myself, and I am unanimous in that!
              • Nigel
                RAM, no. My program is already too big. I would be quite happy if I could just load it using minicom and the tech arts pod. I have done that before and
                Message 7 of 8 , Jan 5, 2011
                • 0 Attachment
                  RAM, no. My program is already too big. I would be quite happy if I could just load it using minicom and the tech arts pod. I have done that before and can't figure out why I can use ot when running linux!

                  cheers,
                  Nigel


                  --- In gnu-m68hc11@yahoogroups.com, Mike McCarty <Mike.McCarty@...> wrote:
                  >
                  > ve3id wrote:
                  >
                  > [...]
                  >
                  > > I can load it and list the source code from within gdb, I can exmaine
                  > > memory in the chip, and I can step through a program that I load into
                  > > flash using windoze!
                  >
                  > Can you get it to load into RAM? Perhaps GDB just doesn't know
                  > how to program FLASH. Different chips have different sector
                  > sizes and all that, so maybe that's the failure. The GDB
                  > team didn't want to build a bunch of knowledge about chips
                  > into the debugger. GDB doesn't buffer up a whole sector, so
                  > after each byte (or word, or whatever) it puts there, the
                  > FLASH starts an erase, and then comes along some more data
                  > which don't make it.
                  >
                  > Mike
                  > --
                  > p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
                  > Oppose globalization and One World Governments like the UN.
                  > This message made from 100% recycled bits.
                  > You have found the bank of Larn.
                  > I speak only for myself, and I am unanimous in that!
                  >
                • Mike McCarty
                  ... I didn t make my question clear, I guess. Can you load _any_ program into RAM? If you can, then it s probably just that GDB doesn t know the specifics of
                  Message 8 of 8 , Jan 6, 2011
                  • 0 Attachment
                    Nigel wrote:
                    > RAM, no. My program is already too big. I would be quite happy if I
                    > could just load it using minicom and the tech arts pod. I have done
                    > that before and can't figure out why I can use ot when running linux!

                    I didn't make my question clear, I guess. Can you load _any_ program
                    into RAM? If you can, then it's probably just that GDB doesn't
                    know the specifics of how to write to the FLASH. I'm trying to
                    decompose your problem into testable pieces. If it can't load a
                    small program into RAM, then there is a more fundamental problem.

                    Mike
                    --
                    p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
                    Oppose globalization and One World Governments like the UN.
                    This message made from 100% recycled bits.
                    You have found the bank of Larn.
                    I speak only for myself, and I am unanimous in that!
                  Your message has been successfully submitted and would be delivered to recipients shortly.