January 2024 - pacsat-dev - mailman.amsat.org

Re: Info about debug device
by Burns Fisher (AMSAT) 09 Jan '24

09 Jan '24

Thanks Bob. I now have the parts, but have had nothing but trouble both removing and replacing those dumb little connectors! Any hints? Are you using hot air or a small iron? 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Jan 9, 2024 at 1:04 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I received the two Devpack programming boards from Burns. Replaced > connectors on both boards and I have tested them on the Quad board and they > both worked fine. > > Returning one of these to Burns today. > > Bob > > > On Jan 5, 2024, at 11:21 AM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I included a little extra. The connectors that I had ordered just arrived > (hot off the plane from Singapore) and I realized that Newark Electroncis > had apparently switched the part number around on me, and they were surface > mount! Not useful for me in this case, but if they are useful for anything > you build, I sent you a few. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Fri, Jan 5, 2024 at 11:28 AM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Thank you sir. >> >> Bob >> >> On Jan 5, 2024, at 10:09 AM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> >> BTW, I'm putting both in the same box but including all the instructions >> that came with it. Note that the instructions assume you are going to be >> using this with a thing called a SensorTag so you can ignore them :-) >> >> I don't care which one you return to be with the connector replace, btw. >> >> Good luck! >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Fri, Jan 5, 2024 at 10:59 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> Bob, et al: >>> >>> FWIW, the official name of the little boards I'm send is TI Simplelink >>> SensorTag Devpack. >>> >>> I'm including a photo of the one that works. You can see when you look >>> at a new one) that the replacement connector goes on the opposite side of >>> the board from the existing 10-pin connector. The existing one is female >>> with no key. The new one is male with shroud and key. The key is on the >>> outside edge of the board, and the connector is on the opposite side of the >>> board from the chip (on the same side as the larger connector. >>> >>> I tried to load code using it (despite not being connect to the RTIHU) >>> and got the attached error message. I used the xdsdfu utility that the >>> error talks about and discovered this: >>> >>> ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -e >>> >>> USB Device Firmware Upgrade Utility >>> Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights >>> reserved. >>> >>> Scanning USB buses for supported XDS110 devices... >>> <<<< Device 0 >>>> >>> VID: 0x0451 PID: 0xbef3 >>> Device Name: XDS110 with CMSIS-DAP >>> Version: 2.2.5.1 >>> Manufacturer: Texas Instruments >>> Serial Num: L787 >>> Mode: Runtime >>> Configuration: Standard >>> Found 1 device. >>> >>> Notice the serial number L787. One of my working ones has the serial >>> number L3122222. So letter L and 7 digits. I am setting yours to >>> L31444444 and L31555555. Like this: >>> >>> >>> bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu >>> -m >>> USB Device Firmware Upgrade Utility >>> Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights >>> reserved. >>> Scanning USB buses for supported XDS110 devices... >>> <<<< Device 0 >>>> >>> VID: 0x0451 PID: 0xbef3 >>> Device Name: XDS110 with CMSIS-DAP >>> Version: 2.2.5.1 >>> Manufacturer: Texas Instruments >>> Serial Num: L787 >>> Mode: Runtime >>> Configuration: Standard >>> Switching device into DFU mode. >>> >>> bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu >>> -s L3144444 -r >>> USB Device Firmware Upgrade Utility >>> Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights >>> reserved. >>> Scanning USB buses for supported XDS110 devices... >>> Setting serial number to "L3144444"... >>> >>> And now the box asks me to select whether I want to use >>> TIXDS110_Connection-S/N:L31444444. I said yes, and it said to update the >>> firmware from 2.2.5.1 to 3.0.0.15 (and there was an update button). This >>> works ok, and now since I am not connected to the RTIHU, it is correctly >>> claiming that it can't connect to the target. >>> >>> I'll update the serial and firmware on the second one I send you as well. >>> >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Info about debug device
by Bob Stricklin 09 Jan '24

09 Jan '24

I received the two Devpack programming boards from Burns. Replaced connectors on both boards and I have tested them on the Quad board and they both worked fine. Returning one of these to Burns today. Bob On Jan 5, 2024, at 11:21 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I included a little extra. The connectors that I had ordered just arrived (hot off the plane from Singapore) and I realized that Newark Electroncis had apparently switched the part number around on me, and they were surface mount! Not useful for me in this case, but if they are useful for anything you build, I sent you a few. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Fri, Jan 5, 2024 at 11:28 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Thank you sir. Bob On Jan 5, 2024, at 10:09 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: BTW, I'm putting both in the same box but including all the instructions that came with it. Note that the instructions assume you are going to be using this with a thing called a SensorTag so you can ignore them :-) I don't care which one you return to be with the connector replace, btw. Good luck! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Fri, Jan 5, 2024 at 10:59 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Bob, et al: FWIW, the official name of the little boards I'm send is TI Simplelink SensorTag Devpack. I'm including a photo of the one that works. You can see when you look at a new one) that the replacement connector goes on the opposite side of the board from the existing 10-pin connector. The existing one is female with no key. The new one is male with shroud and key. The key is on the outside edge of the board, and the connector is on the opposite side of the board from the chip (on the same side as the larger connector. I tried to load code using it (despite not being connect to the RTIHU) and got the attached error message. I used the xdsdfu utility that the error talks about and discovered this: ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -e USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... <<<< Device 0 >>>> VID: 0x0451 PID: 0xbef3 Device Name: XDS110 with CMSIS-DAP Version: 2.2.5.1 Manufacturer: Texas Instruments Serial Num: L787 Mode: Runtime Configuration: Standard Found 1 device. Notice the serial number L787. One of my working ones has the serial number L3122222. So letter L and 7 digits. I am setting yours to L31444444 and L31555555. Like this: bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -m USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... <<<< Device 0 >>>> VID: 0x0451 PID: 0xbef3 Device Name: XDS110 with CMSIS-DAP Version: 2.2.5.1 Manufacturer: Texas Instruments Serial Num: L787 Mode: Runtime Configuration: Standard Switching device into DFU mode. bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -s L3144444 -r USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... Setting serial number to "L3144444"... And now the box asks me to select whether I want to use TIXDS110_Connection-S/N:L31444444. I said yes, and it said to update the firmware from 2.2.5.1 to 3.0.0.15 (and there was an update button). This works ok, and now since I am not connected to the RTIHU, it is correctly claiming that it can't connect to the target. I'll update the serial and firmware on the second one I send you as well. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

MAX4995
by Bob Stricklin 06 Jan '24

06 Jan '24

I see the MAX4995 has a minimum supply voltage requirement of 1.7V volts so I will take it out of the circuit. The TMS570 has some complex power up conditions in voltage and timing. If not correct the chip can go into a constant reseting mode like I was seeing. Something that may need more study. I can see where this would all work fine in a prototype but be on the edge and when in space operating at hot of cold have an issue on startup. Initially I checked out the supplies with no CPU and all looks fine and constant. I measured them many times with a volt meter but I could not see this reset glitch happening. I finally did look ant the error output pin on the CPU and this was the point I realized there was an issue. There is about 2 uf of bypass and 22 uf of filter/loop capacitance on the 1.2 volt supply that all has to get up and stabilized. In some systems this would all happen before the power is handed over to the TMS570. The power up delays in the TMS570 may be enough to take care of this if it does not mind some instability while in the delay which is in the order of a millisecond. The TMS570 will not allow the 1.2 volt signal to fall below 0.9 volts typically and above 2.1 volts typically. On a worst case bases this could be squeezed to 1.13 volts min 1.40 volts max. I took out all the extra resistors I penciled into the JTAG interface. May be able to take out more. I think EMUn needs to be pulled down low not high. I have connected them this way because I was seeing EMU interrupts in the startup error messages earlier. They are not there on the 10 pin version of the JTAG programmer. I will test it early next week but I think it will work fine and be simpler to deal with. I see not startup error messages now when loading code. Bob

1 0

Re: Board is working
by Chris Thompson 06 Jan '24

06 Jan '24

Wow, well done Bob. That is fantastic progress! 73 Chris On Sat, Jan 6, 2024, 18:19 Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > CONGRATS!!! > > > > Take the night off and then get back to work. > > > > Could be blinking real fast. The original loop program on the LaunchPad > did and I thought I slowed them down but could have forgotten or missed a > step. > > I’ll look at the code. > > > > Jim > > WA4CWI > > > > I finally figured out what was causing the issue. > > > > The 1.2 volt supply was dropping out due to the MAX4995ALAUT current > limiting device. The 4995 was set to support up to 600 mA. Either the > device is bad or it can not deal with 1.2 volts. > > I changed the current limit program resistor to allow 700 mA over the > recommend amount and it still dropped out. The large current rush may also > happen at startup and drop back after the device is running. > > > > I noticed the TMS570 error lin was dropping and the nRST line was > constantly cycling. So the CPU was reseting over and over and the JTAG > never had a chance. > > > > Need to study the MAX4995 data sheet more and maybe try another MAX4995 > which I have. If it still gives trouble I will try wiring around it and see > if the 1.2V power supply will support this. I really do not like the pulse > width modulated regulator. It is supposed to be very efficient but > efficiency comes with some issues on the output voltage. > > > > I shut the MAX4995 off and connected an external 1.2V supply. Then JTAG > started working and I can load programs. The 1.2V supply has 190 mA on the > meter. > > > > I tried a couple of programs and found the JTAG loads quickly and dropped > into debug window now. > > > > Jim’s Blinky program loaded but the LEDs appear to be full on. At least > they wen from dim to full on indicating the program was doing something. > Probably configuring the outputs as IO and leaving them in a Low state > which would turn on the LEDs. I look at the with a scope later and make > sure it is not blinking real fast. > > > > I loaded the loop program also. It seems to load as well. > > > > I will work on more test programs later. Time for a break now. > > > > Bob > > > > Photo of 1.2 volt supply and the LEDs on but not blinking yet. > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Board is working
by Jim McCullers 06 Jan '24

06 Jan '24

CONGRATS!!! Take the night off and then get back to work. Could be blinking real fast. The original loop program on the LaunchPad did and I thought I slowed them down but could have forgotten or missed a step. I’ll look at the code. Jim WA4CWI I finally figured out what was causing the issue. The 1.2 volt supply was dropping out due to the MAX4995ALAUT current limiting device. The 4995 was set to support up to 600 mA. Either the device is bad or it can not deal with 1.2 volts. I changed the current limit program resistor to allow 700 mA over the recommend amount and it still dropped out. The large current rush may also happen at startup and drop back after the device is running. I noticed the TMS570 error lin was dropping and the nRST line was constantly cycling. So the CPU was reseting over and over and the JTAG never had a chance. Need to study the MAX4995 data sheet more and maybe try another MAX4995 which I have. If it still gives trouble I will try wiring around it and see if the 1.2V power supply will support this. I really do not like the pulse width modulated regulator. It is supposed to be very efficient but efficiency comes with some issues on the output voltage. I shut the MAX4995 off and connected an external 1.2V supply. Then JTAG started working and I can load programs. The 1.2V supply has 190 mA on the meter. I tried a couple of programs and found the JTAG loads quickly and dropped into debug window now. Jim’s Blinky program loaded but the LEDs appear to be full on. At least they wen from dim to full on indicating the program was doing something. Probably configuring the outputs as IO and leaving them in a Low state which would turn on the LEDs. I look at the with a scope later and make sure it is not blinking real fast. I loaded the loop program also. It seems to load as well. I will work on more test programs later. Time for a break now. Bob Photo of 1.2 volt supply and the LEDs on but not blinking yet.

1 0

Board is working
by Bob Stricklin 06 Jan '24

06 Jan '24

I finally figured out what was causing the issue. The 1.2 volt supply was dropping out due to the MAX4995ALAUT current limiting device. The 4995 was set to support up to 600 mA. Either the device is bad or it can not deal with 1.2 volts. I changed the current limit program resistor to allow 700 mA over the recommend amount and it still dropped out. The large current rush may also happen at startup and drop back after the device is running. I noticed the TMS570 error lin was dropping and the nRST line was constantly cycling. So the CPU was reseting over and over and the JTAG never had a chance. Need to study the MAX4995 data sheet more and maybe try another MAX4995 which I have. If it still gives trouble I will try wiring around it and see if the 1.2V power supply will support this. I really do not like the pulse width modulated regulator. It is supposed to be very efficient but efficiency comes with some issues on the output voltage. I shut the MAX4995 off and connected an external 1.2V supply. Then JTAG started working and I can load programs. The 1.2V supply has 190 mA on the meter. I tried a couple of programs and found the JTAG loads quickly and dropped into debug window now. Jim’s Blinky program loaded but the LEDs appear to be full on. At least they wen from dim to full on indicating the program was doing something. Probably configuring the outputs as IO and leaving them in a Low state which would turn on the LEDs. I look at the with a scope later and make sure it is not blinking real fast. I loaded the loop program also. It seems to load as well. I will work on more test programs later. Time for a break now. Bob Photo of 1.2 volt supply and the LEDs on but not blinking yet. [cid:E6572D54-0A19-4E79-B882-0683DB982CE1@StricklinRanch.com][cid:85663A26-95EF-47D0-9BFD-D0D9E28FB13E@StricklinRanch.com]

1 0

Re: Info about debug device
by Burns Fisher (AMSAT) 05 Jan '24

05 Jan '24

I included a little extra. The connectors that I had ordered just arrived (hot off the plane from Singapore) and I realized that Newark Electroncis had apparently switched the part number around on me, and they were surface mount! Not useful for me in this case, but if they are useful for anything you build, I sent you a few. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Jan 5, 2024 at 11:28 AM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Thank you sir. > > Bob > > On Jan 5, 2024, at 10:09 AM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > > BTW, I'm putting both in the same box but including all the instructions > that came with it. Note that the instructions assume you are going to be > using this with a thing called a SensorTag so you can ignore them :-) > > I don't care which one you return to be with the connector replace, btw. > > Good luck! > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Fri, Jan 5, 2024 at 10:59 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> Bob, et al: >> >> FWIW, the official name of the little boards I'm send is TI Simplelink >> SensorTag Devpack. >> >> I'm including a photo of the one that works. You can see when you look >> at a new one) that the replacement connector goes on the opposite side of >> the board from the existing 10-pin connector. The existing one is female >> with no key. The new one is male with shroud and key. The key is on the >> outside edge of the board, and the connector is on the opposite side of the >> board from the chip (on the same side as the larger connector. >> >> I tried to load code using it (despite not being connect to the RTIHU) >> and got the attached error message. I used the xdsdfu utility that the >> error talks about and discovered this: >> >> ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -e >> >> USB Device Firmware Upgrade Utility >> Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights >> reserved. >> >> Scanning USB buses for supported XDS110 devices... >> <<<< Device 0 >>>> >> VID: 0x0451 PID: 0xbef3 >> Device Name: XDS110 with CMSIS-DAP >> Version: 2.2.5.1 >> Manufacturer: Texas Instruments >> Serial Num: L787 >> Mode: Runtime >> Configuration: Standard >> Found 1 device. >> >> Notice the serial number L787. One of my working ones has the serial >> number L3122222. So letter L and 7 digits. I am setting yours to >> L31444444 and L31555555. Like this: >> >> >> bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -m >> USB Device Firmware Upgrade Utility >> Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights >> reserved. >> Scanning USB buses for supported XDS110 devices... >> <<<< Device 0 >>>> >> VID: 0x0451 PID: 0xbef3 >> Device Name: XDS110 with CMSIS-DAP >> Version: 2.2.5.1 >> Manufacturer: Texas Instruments >> Serial Num: L787 >> Mode: Runtime >> Configuration: Standard >> Switching device into DFU mode. >> >> bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu >> -s L3144444 -r >> USB Device Firmware Upgrade Utility >> Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights >> reserved. >> Scanning USB buses for supported XDS110 devices... >> Setting serial number to "L3144444"... >> >> And now the box asks me to select whether I want to use >> TIXDS110_Connection-S/N:L31444444. I said yes, and it said to update the >> firmware from 2.2.5.1 to 3.0.0.15 (and there was an update button). This >> works ok, and now since I am not connected to the RTIHU, it is correctly >> claiming that it can't connect to the target. >> >> I'll update the serial and firmware on the second one I send you as well. >> >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Info about debug device
by Bob Stricklin 05 Jan '24

05 Jan '24

Thank you sir. Bob On Jan 5, 2024, at 10:09 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: BTW, I'm putting both in the same box but including all the instructions that came with it. Note that the instructions assume you are going to be using this with a thing called a SensorTag so you can ignore them :-) I don't care which one you return to be with the connector replace, btw. Good luck! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Fri, Jan 5, 2024 at 10:59 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Bob, et al: FWIW, the official name of the little boards I'm send is TI Simplelink SensorTag Devpack. I'm including a photo of the one that works. You can see when you look at a new one) that the replacement connector goes on the opposite side of the board from the existing 10-pin connector. The existing one is female with no key. The new one is male with shroud and key. The key is on the outside edge of the board, and the connector is on the opposite side of the board from the chip (on the same side as the larger connector. I tried to load code using it (despite not being connect to the RTIHU) and got the attached error message. I used the xdsdfu utility that the error talks about and discovered this: ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -e USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... <<<< Device 0 >>>> VID: 0x0451 PID: 0xbef3 Device Name: XDS110 with CMSIS-DAP Version: 2.2.5.1 Manufacturer: Texas Instruments Serial Num: L787 Mode: Runtime Configuration: Standard Found 1 device. Notice the serial number L787. One of my working ones has the serial number L3122222. So letter L and 7 digits. I am setting yours to L31444444 and L31555555. Like this: bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -m USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... <<<< Device 0 >>>> VID: 0x0451 PID: 0xbef3 Device Name: XDS110 with CMSIS-DAP Version: 2.2.5.1 Manufacturer: Texas Instruments Serial Num: L787 Mode: Runtime Configuration: Standard Switching device into DFU mode. bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -s L3144444 -r USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... Setting serial number to "L3144444"... And now the box asks me to select whether I want to use TIXDS110_Connection-S/N:L31444444. I said yes, and it said to update the firmware from 2.2.5.1 to 3.0.0.15 (and there was an update button). This works ok, and now since I am not connected to the RTIHU, it is correctly claiming that it can't connect to the target. I'll update the serial and firmware on the second one I send you as well. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Info about debug device
by Burns Fisher (AMSAT) 05 Jan '24

05 Jan '24

Bob, et al: FWIW, the official name of the little boards I'm send is TI Simplelink SensorTag Devpack. I'm including a photo of the one that works. You can see when you look at a new one) that the replacement connector goes on the opposite side of the board from the existing 10-pin connector. The existing one is female with no key. The new one is male with shroud and key. The key is on the outside edge of the board, and the connector is on the opposite side of the board from the chip (on the same side as the larger connector. I tried to load code using it (despite not being connect to the RTIHU) and got the attached error message. I used the xdsdfu utility that the error talks about and discovered this: ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -e USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... <<<< Device 0 >>>> VID: 0x0451 PID: 0xbef3 Device Name: XDS110 with CMSIS-DAP Version: 2.2.5.1 Manufacturer: Texas Instruments Serial Num: L787 Mode: Runtime Configuration: Standard Found 1 device. Notice the serial number L787. One of my working ones has the serial number L3122222. So letter L and 7 digits. I am setting yours to L31444444 and L31555555. Like this: bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -m USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... <<<< Device 0 >>>> VID: 0x0451 PID: 0xbef3 Device Name: XDS110 with CMSIS-DAP Version: 2.2.5.1 Manufacturer: Texas Instruments Serial Num: L787 Mode: Runtime Configuration: Standard Switching device into DFU mode. bfisher@skylab:~$ ./ti/ccs1020/ccs/ccs_base/common/uscif/xds110/xdsdfu -s L3144444 -r USB Device Firmware Upgrade Utility Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved. Scanning USB buses for supported XDS110 devices... Setting serial number to "L3144444"... And now the box asks me to select whether I want to use TIXDS110_Connection-S/N:L31444444. I said yes, and it said to update the firmware from 2.2.5.1 to 3.0.0.15 (and there was an update button). This works ok, and now since I am not connected to the RTIHU, it is correctly claiming that it can't connect to the target. I'll update the serial and firmware on the second one I send you as well. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 1

Messages from Test Device and Errors for a test code load.
by Bob Stricklin 04 Jan '24

04 Jan '24

Test Device shows some error but it may be the results are fine since it says succeeded. The error info may be related to a config issue in HalCoGen or the ID number Burns was telling us about. May also be the JTAG is not correct yet. Bob

1 0