- pacsat-dev - mailman.amsat.org

Re: Quick test for AX5043
by Bob Stricklin 08 Feb '24

08 Feb '24

I resolved the issue with GIT I had. I was setting things up initially with my GIT username and password and apparently you must in CCS. I have built and run Version ‘o’. I am seeing data back from 2 of the AX5043s. Probably need to expand code to work with all 4 devices. Later. get ax returns this …. screen capture [cid:EF20FB88-7227-4FC8-959E-23671DB65BEC@StricklinRanch.com] get mram size just returns two of the mram 0 and 2 and indicates their size is 0k. test mram 1 42 seems to run saying Write starting at etc and goes from 0KB to 1024KB. Then it does a Read in same area and does not report any errors but says: Test is OK! Time is 75 seconds. MRAM chips are 4 meg so maybe code only setup for 1 meg. More testing on hardware later today. Bob On Feb 7, 2024, at 10:47 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Yes, the same branch. What errors are you getting? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Feb 7, 2024 at 11:33 AM Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> wrote: Burns, Confirm for me the branch you are working with is WB1FJ_Port_to_Blinky I am having an issue getting a clean build. I know you were still working CS problem but I am trying to get the GIT build process to work properly. Bob On Feb 6, 2024, at 5:34 PM, Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> wrote: OK Bob On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I'm reasonably sure that I have the chip select lines screwed up in s/w. I have band rehearsal tonight, so I won't be able to do anything till tomorrow. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Feb 6, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: I added a quick test to tell if the 5043 SPI interface is working. This is in version 0.1n and has been pushed upstream. Pacsat>test ax AX5043 #0: Revision=7, scratch=7 AX5043 #1: Revision=7, scratch=7 AX5043 #2: Revision=119, scratch=119 AX5043 #3: Revision=7, scratch=7 AX5043 #4: Revision=119, scratch=119 AX5043 #5: Revision=7, scratch=7 This is what it looks like. However the numbers are all wrong. I'm not sure how they can be other than right or 0xff, but something is screwed up. The Revision should be 0x51, which would be printed in decimal as 81. The scratch register, I wrote the AX5043 number into, so each one should read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. You might as well try it on yours Bob. In the meantime, I'll try to see if I can tell anything on mine. 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/>

1 0

Re: AX5043 SPI working on Blinky
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

Hi Bob, Golf meeting tonight so I can't do any more. But the screenshots are very low res--I can't really read them. I'll see what I can tell from the text. Or maybe Chris can see something--he is better with git than I am. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Wed, Feb 7, 2024 at 8:31 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, thanks for all your work and the comments. > > I was out most of the day and just getting to look at this. > > All your comments look like minor things we can work to improve on. The > key thing I see is that you are talking to AX5043. Let me look at the > clock ringing when i get a valid build of Version ‘O’. > We may need to add some small series resistance on the lines. I will also > take a look with and without the pull-ups. This can also be related to the > capacitance of the scope probe and how you are grounding the probe. Since > it is writing and reading it must not be getting double/multi clocked. > > The PA section is not working on your board for sure. Still looking at > that myself. While some would like more power we do not have to have that > to do a lot of radio testing. > > Your comments about SPI working correctly is something to address with > code (verification of expected W/R) on this board and other AMSAT projects. > > I would say to hold on to that board until you have a replacement in hand > then ship it back to me. Should be soon I got the 3D boxes and just need to > make the known changes to all three boards. Hope to move the boards along > tomorrow. Now if you want it out of house so it is not on your mind and > pull at you then go ahead. > > Still have a GIT issue of some sort. I am attaching a series of photos of > my screens to show you what I am seeing. It looks like a permissions issue. > The only way I have made it work on Version M was to pull the GIT in linux > then move everything to Windows. If I stop doing anything with HCG I can > just switch to Windows. > > Have seen the wrong processor show up starting with the processor used on > the Launchpad board. We can fix this in the long run but having the code > for different hardware in the same repository seems like a possible issue > for any new AMSAT helpers to understand and deal with. > > Here are GIT screen shots: > > You can see I tried to do a Pull, then a fetch pull. There is a little > black check mark on the Blinky and that is the one in Project Explore > window. This will not build an ‘out' file though and I see in config.h a > version ‘1k’ if that is where the version reported lives. So probably not > getting the most up-to-date code. > > > Bob > > > > > > On Feb 7, 2024, at 6:34 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > BTW, I think Bob noticed this but I did not understand till today: > > I accidentally set up the HalCoGen setup as being for a TMS570LS0714PGE, > not a 914. It turns out the only difference between the chips is the > amount of flash memory, so it probably won't hurt anything till we start > getting more and more code. I'd guess the only difference in the generated > code is the linker script. I may try to fix it some time, but for now I'll > just let it go. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Wed, Feb 7, 2024 at 5:59 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> One disadvantage to SPI is that there is no way that the code can really >> tell if it did not work. If it totally fails, the return value is 0xff. >> It is certainly easy enough to put in a default value if what is read is >> out of range. Probably a good idea even for permanently. The main reason >> for the MRAM is so that the frequency can be tweaked if the crystal is a >> bit off. Give me some values, and I can add that easily. I have no idea >> if the other 5043 register values are reasonable, but give that several >> registers seem to be fine, I'd guess that they are real if not right. >> >> Actually, I'm not sure if the PA is working. Bob was doing some work on >> it last I remember. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Wed, Feb 7, 2024 at 5:52 PM Chris Thompson <chrisethompson(a)gmail.com> >> wrote: >> >>> Very good progress Burns, well done. >>> >>> We might want to set the radio frequency to a default if the MRAM can >>> not be read. At least then we would get some telem perhaps. Does the MRAM >>> read fail with an error or it just reads garbage but appears to work? >>> >>> Anyway, we could put a range check and if the frequency is outside a >>> range we could set to default. >>> >>> 73 >>> Chris >>> >>> On Wed, Feb 7, 2024, 17:45 Burns Fisher (AMSAT) via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> Here is my test command. It reads the hardware revision registers >>>> (0x51...correct according to the documentation) and then it writes the chip >>>> number into the scratch register on the chip and reads it back. As you can >>>> see, that is working: >>>> >>>> AMSAT-NA PacSat Console >>>> Flight Software X0.1o (built on Feb 7 2024 at 17:07:06) >>>> <all sorts of error messages due to MRAM not working elided> >>>> Pacsat>test ax >>>> AX5043 #0: Revision=0x51, scratch=0 >>>> AX5043 #1: Revision=0x51, scratch=1 >>>> AX5043 #2: Revision=0x51, scratch=2 >>>> AX5043 #3: Revision=0x51, scratch=3 >>>> AX5043 #4: Revision=0x51, scratch=4 >>>> AX5043 #5: Revision=0x51, scratch=5 >>>> >>>> I also looked at the frequency. With the MRAM not working, it is >>>> probably somewhat random, so I tried setting it, and it appears that it >>>> changed at least. Note that you can't just set the frequency from the >>>> console, nor can you change it by a large amount. I just kept repeating >>>> 99999 (probably 65535 is the largest) till it got down to where you see it. >>>> >>>> Pacsat>>lower tx freq 99999 >>>> TxFreq=434908591 >>>> Pacsat>>lower tx freq 99999 >>>> TxFreq=434874128 >>>> Pacsat>>lower tx freq 99999 >>>> TxFreq=434839665 >>>> get ax >>>> <receive 0 elided> >>>> AX5043 dev 4 Tx: >>>> FIFOSTAT: 00 >>>> PWRMODE: 60 >>>> XTALCAP: 0 >>>> PLLLOOP: 09 >>>> PLLCPI: 08 >>>> PLLVCOI: 12 >>>> PLLRANGINGA: 08 >>>> PLLVCODIV: 00 >>>> FREQ 434839665 Hz >>>> MODULATION: 8 >>>> TXPWRCOEFFB0: ff >>>> TXPWRCOEFFB1: f >>>> >>>> So the fact that "get ax" read back the same frequency value as was >>>> written is good. I also tried "test pll" but that only is set up for 2m >>>> which we know will not work because of the missing inductor. >>>> >>>> A couple odd things. Notice the scope trace attached. Yellow is >>>> CLK. Magenta is (supposedly) MOSI, Cyan is MISO. I did not record any >>>> chip select lines. I'm guessing that I don't have the MOSI wire soldered >>>> well, or else the header holes are wrong or some such. Obviously MOSI is >>>> working or we would not have most of the above working. But look at the >>>> clock signal. I find the overshoot and undershoot worrysome. There is a >>>> bit of ringing on the square parts of the signal, but the volt or so >>>> overshoot at either end seems odd. The MOSI does appear as though there is >>>> some capacitance on the line except that when it goes up or down to match >>>> the clock it is quick. So that is probably the chip when chip-select is >>>> activated. >>>> >>>> BTW, what you see there are first 16 clock pulses where the data on >>>> MOSI should be 0 (saying read register 0). At the same time the data on >>>> MISO gives that status (which I don't think gets used). Then a brief space >>>> and you see 8 clock pulses clocking out the 8 bits of register 0 (0x51) on >>>> MISO. >>>> >>>> Anyway, this code is version X0.1o (letter o) and is checked in and >>>> pushed upstream. >>>> >>>> BTW, I don't think any of the pullups are required in SPI (R801-R809) >>>> since despite being a bus, SPI uses push/pull i/o. Could that relate to >>>> the overshoot? >>>> >>>> Bob, I'm thinking to return my current Blinky and ask you to give me >>>> one (no rush--I've got Golf work to do) with MRAMs that work. Perhaps the >>>> one you have with two working has a s/w problem with the other 2...I'm not >>>> sure, but it is way easier to debug when SOMETHING works :-) What do you >>>> think? >>>> >>>> Burns >>>> >>>> >>>> 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 >

1 0

Re: AX5043 SPI working on Blinky
by Bob Stricklin 08 Feb '24

08 Feb '24

Burns, thanks for all your work and the comments. I was out most of the day and just getting to look at this. All your comments look like minor things we can work to improve on. The key thing I see is that you are talking to AX5043. Let me look at the clock ringing when i get a valid build of Version ‘O’. We may need to add some small series resistance on the lines. I will also take a look with and without the pull-ups. This can also be related to the capacitance of the scope probe and how you are grounding the probe. Since it is writing and reading it must not be getting double/multi clocked. The PA section is not working on your board for sure. Still looking at that myself. While some would like more power we do not have to have that to do a lot of radio testing. Your comments about SPI working correctly is something to address with code (verification of expected W/R) on this board and other AMSAT projects. I would say to hold on to that board until you have a replacement in hand then ship it back to me. Should be soon I got the 3D boxes and just need to make the known changes to all three boards. Hope to move the boards along tomorrow. Now if you want it out of house so it is not on your mind and pull at you then go ahead. Still have a GIT issue of some sort. I am attaching a series of photos of my screens to show you what I am seeing. It looks like a permissions issue. The only way I have made it work on Version M was to pull the GIT in linux then move everything to Windows. If I stop doing anything with HCG I can just switch to Windows. Have seen the wrong processor show up starting with the processor used on the Launchpad board. We can fix this in the long run but having the code for different hardware in the same repository seems like a possible issue for any new AMSAT helpers to understand and deal with. Here are GIT screen shots: You can see I tried to do a Pull, then a fetch pull. There is a little black check mark on the Blinky and that is the one in Project Explore window. This will not build an ‘out' file though and I see in config.h a version ‘1k’ if that is where the version reported lives. So probably not getting the most up-to-date code. [cid:686292EA-A4DB-4050-A49F-5A55E3819CB6@StricklinRanch.com][cid:4D61B619-143A-40EB-B729-FCE63C3D0969@StricklinRanch.com][cid:080C75A2-9F51-4AB6-82AE-3ECE166E1FAC@StricklinRanch.com][cid:87515749-37A9-42E3-B1CA-6976FAC803CB@StricklinRanch.com] Bob On Feb 7, 2024, at 6:34 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: BTW, I think Bob noticed this but I did not understand till today: I accidentally set up the HalCoGen setup as being for a TMS570LS0714PGE, not a 914. It turns out the only difference between the chips is the amount of flash memory, so it probably won't hurt anything till we start getting more and more code. I'd guess the only difference in the generated code is the linker script. I may try to fix it some time, but for now I'll just let it go. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Feb 7, 2024 at 5:59 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: One disadvantage to SPI is that there is no way that the code can really tell if it did not work. If it totally fails, the return value is 0xff. It is certainly easy enough to put in a default value if what is read is out of range. Probably a good idea even for permanently. The main reason for the MRAM is so that the frequency can be tweaked if the crystal is a bit off. Give me some values, and I can add that easily. I have no idea if the other 5043 register values are reasonable, but give that several registers seem to be fine, I'd guess that they are real if not right. Actually, I'm not sure if the PA is working. Bob was doing some work on it last I remember. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Feb 7, 2024 at 5:52 PM Chris Thompson <chrisethompson(a)gmail.com<mailto:chrisethompson@gmail.com>> wrote: Very good progress Burns, well done. We might want to set the radio frequency to a default if the MRAM can not be read. At least then we would get some telem perhaps. Does the MRAM read fail with an error or it just reads garbage but appears to work? Anyway, we could put a range check and if the frequency is outside a range we could set to default. 73 Chris On Wed, Feb 7, 2024, 17:45 Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Here is my test command. It reads the hardware revision registers (0x51...correct according to the documentation) and then it writes the chip number into the scratch register on the chip and reads it back. As you can see, that is working: AMSAT-NA PacSat Console Flight Software X0.1o (built on Feb 7 2024 at 17:07:06) <all sorts of error messages due to MRAM not working elided> Pacsat>test ax AX5043 #0: Revision=0x51, scratch=0 AX5043 #1: Revision=0x51, scratch=1 AX5043 #2: Revision=0x51, scratch=2 AX5043 #3: Revision=0x51, scratch=3 AX5043 #4: Revision=0x51, scratch=4 AX5043 #5: Revision=0x51, scratch=5 I also looked at the frequency. With the MRAM not working, it is probably somewhat random, so I tried setting it, and it appears that it changed at least. Note that you can't just set the frequency from the console, nor can you change it by a large amount. I just kept repeating 99999 (probably 65535 is the largest) till it got down to where you see it. Pacsat>>lower tx freq 99999 TxFreq=434908591 Pacsat>>lower tx freq 99999 TxFreq=434874128 Pacsat>>lower tx freq 99999 TxFreq=434839665 get ax <receive 0 elided> AX5043 dev 4 Tx: FIFOSTAT: 00 PWRMODE: 60 XTALCAP: 0 PLLLOOP: 09 PLLCPI: 08 PLLVCOI: 12 PLLRANGINGA: 08 PLLVCODIV: 00 FREQ 434839665 Hz MODULATION: 8 TXPWRCOEFFB0: ff TXPWRCOEFFB1: f So the fact that "get ax" read back the same frequency value as was written is good. I also tried "test pll" but that only is set up for 2m which we know will not work because of the missing inductor. A couple odd things. Notice the scope trace attached. Yellow is CLK. Magenta is (supposedly) MOSI, Cyan is MISO. I did not record any chip select lines. I'm guessing that I don't have the MOSI wire soldered well, or else the header holes are wrong or some such. Obviously MOSI is working or we would not have most of the above working. But look at the clock signal. I find the overshoot and undershoot worrysome. There is a bit of ringing on the square parts of the signal, but the volt or so overshoot at either end seems odd. The MOSI does appear as though there is some capacitance on the line except that when it goes up or down to match the clock it is quick. So that is probably the chip when chip-select is activated. BTW, what you see there are first 16 clock pulses where the data on MOSI should be 0 (saying read register 0). At the same time the data on MISO gives that status (which I don't think gets used). Then a brief space and you see 8 clock pulses clocking out the 8 bits of register 0 (0x51) on MISO. Anyway, this code is version X0.1o (letter o) and is checked in and pushed upstream. BTW, I don't think any of the pullups are required in SPI (R801-R809) since despite being a bus, SPI uses push/pull i/o. Could that relate to the overshoot? Bob, I'm thinking to return my current Blinky and ask you to give me one (no rush--I've got Golf work to do) with MRAMs that work. Perhaps the one you have with two working has a s/w problem with the other 2...I'm not sure, but it is way easier to debug when SOMETHING works :-) What do you think? Burns 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

1 0

Re: AX5043 SPI working on Blinky
by Chris Thompson 08 Feb '24

08 Feb '24

Very good progress Burns, well done. We might want to set the radio frequency to a default if the MRAM can not be read. At least then we would get some telem perhaps. Does the MRAM read fail with an error or it just reads garbage but appears to work? Anyway, we could put a range check and if the frequency is outside a range we could set to default. 73 Chris On Wed, Feb 7, 2024, 17:45 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Here is my test command. It reads the hardware revision registers > (0x51...correct according to the documentation) and then it writes the chip > number into the scratch register on the chip and reads it back. As you can > see, that is working: > > AMSAT-NA PacSat Console > Flight Software X0.1o (built on Feb 7 2024 at 17:07:06) > <all sorts of error messages due to MRAM not working elided> > Pacsat>test ax > AX5043 #0: Revision=0x51, scratch=0 > AX5043 #1: Revision=0x51, scratch=1 > AX5043 #2: Revision=0x51, scratch=2 > AX5043 #3: Revision=0x51, scratch=3 > AX5043 #4: Revision=0x51, scratch=4 > AX5043 #5: Revision=0x51, scratch=5 > > I also looked at the frequency. With the MRAM not working, it is probably > somewhat random, so I tried setting it, and it appears that it changed at > least. Note that you can't just set the frequency from the console, nor > can you change it by a large amount. I just kept repeating 99999 (probably > 65535 is the largest) till it got down to where you see it. > > Pacsat>>lower tx freq 99999 > TxFreq=434908591 > Pacsat>>lower tx freq 99999 > TxFreq=434874128 > Pacsat>>lower tx freq 99999 > TxFreq=434839665 > get ax > <receive 0 elided> > AX5043 dev 4 Tx: > FIFOSTAT: 00 > PWRMODE: 60 > XTALCAP: 0 > PLLLOOP: 09 > PLLCPI: 08 > PLLVCOI: 12 > PLLRANGINGA: 08 > PLLVCODIV: 00 > FREQ 434839665 Hz > MODULATION: 8 > TXPWRCOEFFB0: ff > TXPWRCOEFFB1: f > > So the fact that "get ax" read back the same frequency value as was > written is good. I also tried "test pll" but that only is set up for 2m > which we know will not work because of the missing inductor. > > A couple odd things. Notice the scope trace attached. Yellow is CLK. > Magenta is (supposedly) MOSI, Cyan is MISO. I did not record any chip > select lines. I'm guessing that I don't have the MOSI wire soldered well, > or else the header holes are wrong or some such. Obviously MOSI is working > or we would not have most of the above working. But look at the clock > signal. I find the overshoot and undershoot worrysome. There is a bit of > ringing on the square parts of the signal, but the volt or so overshoot at > either end seems odd. The MOSI does appear as though there is some > capacitance on the line except that when it goes up or down to match the > clock it is quick. So that is probably the chip when chip-select is > activated. > > BTW, what you see there are first 16 clock pulses where the data on MOSI > should be 0 (saying read register 0). At the same time the data on MISO > gives that status (which I don't think gets used). Then a brief space and > you see 8 clock pulses clocking out the 8 bits of register 0 (0x51) on MISO. > > Anyway, this code is version X0.1o (letter o) and is checked in and pushed > upstream. > > BTW, I don't think any of the pullups are required in SPI (R801-R809) > since despite being a bus, SPI uses push/pull i/o. Could that relate to > the overshoot? > > Bob, I'm thinking to return my current Blinky and ask you to give me one > (no rush--I've got Golf work to do) with MRAMs that work. Perhaps the one > you have with two working has a s/w problem with the other 2...I'm not > sure, but it is way easier to debug when SOMETHING works :-) What do you > think? > > Burns > > > 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 >

2 2

AX5043 SPI working on Blinky
by Burns Fisher (AMSAT) 07 Feb '24

07 Feb '24

Here is my test command. It reads the hardware revision registers (0x51...correct according to the documentation) and then it writes the chip number into the scratch register on the chip and reads it back. As you can see, that is working: AMSAT-NA PacSat Console Flight Software X0.1o (built on Feb 7 2024 at 17:07:06) <all sorts of error messages due to MRAM not working elided> Pacsat>test ax AX5043 #0: Revision=0x51, scratch=0 AX5043 #1: Revision=0x51, scratch=1 AX5043 #2: Revision=0x51, scratch=2 AX5043 #3: Revision=0x51, scratch=3 AX5043 #4: Revision=0x51, scratch=4 AX5043 #5: Revision=0x51, scratch=5 I also looked at the frequency. With the MRAM not working, it is probably somewhat random, so I tried setting it, and it appears that it changed at least. Note that you can't just set the frequency from the console, nor can you change it by a large amount. I just kept repeating 99999 (probably 65535 is the largest) till it got down to where you see it. Pacsat>>lower tx freq 99999 TxFreq=434908591 Pacsat>>lower tx freq 99999 TxFreq=434874128 Pacsat>>lower tx freq 99999 TxFreq=434839665 get ax <receive 0 elided> AX5043 dev 4 Tx: FIFOSTAT: 00 PWRMODE: 60 XTALCAP: 0 PLLLOOP: 09 PLLCPI: 08 PLLVCOI: 12 PLLRANGINGA: 08 PLLVCODIV: 00 FREQ 434839665 Hz MODULATION: 8 TXPWRCOEFFB0: ff TXPWRCOEFFB1: f So the fact that "get ax" read back the same frequency value as was written is good. I also tried "test pll" but that only is set up for 2m which we know will not work because of the missing inductor. A couple odd things. Notice the scope trace attached. Yellow is CLK. Magenta is (supposedly) MOSI, Cyan is MISO. I did not record any chip select lines. I'm guessing that I don't have the MOSI wire soldered well, or else the header holes are wrong or some such. Obviously MOSI is working or we would not have most of the above working. But look at the clock signal. I find the overshoot and undershoot worrysome. There is a bit of ringing on the square parts of the signal, but the volt or so overshoot at either end seems odd. The MOSI does appear as though there is some capacitance on the line except that when it goes up or down to match the clock it is quick. So that is probably the chip when chip-select is activated. BTW, what you see there are first 16 clock pulses where the data on MOSI should be 0 (saying read register 0). At the same time the data on MISO gives that status (which I don't think gets used). Then a brief space and you see 8 clock pulses clocking out the 8 bits of register 0 (0x51) on MISO. Anyway, this code is version X0.1o (letter o) and is checked in and pushed upstream. BTW, I don't think any of the pullups are required in SPI (R801-R809) since despite being a bus, SPI uses push/pull i/o. Could that relate to the overshoot? Bob, I'm thinking to return my current Blinky and ask you to give me one (no rush--I've got Golf work to do) with MRAMs that work. Perhaps the one you have with two working has a s/w problem with the other 2...I'm not sure, but it is way easier to debug when SOMETHING works :-) What do you think? Burns 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Quick test for AX5043
by Burns Fisher (AMSAT) 06 Feb '24

06 Feb '24

I added a quick test to tell if the 5043 SPI interface is working. This is in version 0.1n and has been pushed upstream. Pacsat>test ax AX5043 #0: Revision=7, scratch=7 AX5043 #1: Revision=7, scratch=7 AX5043 #2: Revision=119, scratch=119 AX5043 #3: Revision=7, scratch=7 AX5043 #4: Revision=119, scratch=119 AX5043 #5: Revision=7, scratch=7 This is what it looks like. However the numbers are all wrong. I'm not sure how they can be other than right or 0xff, but something is screwed up. The Revision should be 0x51, which would be printed in decimal as 81. The scratch register, I wrote the AX5043 number into, so each one should read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. You might as well try it on yours Bob. In the meantime, I'll try to see if I can tell anything on mine. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 1

Re: One board now talking
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

At this point we don't even know if the radio SPI is working. Plus most of the tasks are turned off just to simplify debugging. Bob, I pushed upstream the version that should (might???) have the correct chip select lines. Could you please try this one? 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 5:22 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Looks promising but the radio chips have the wrong frequencies. Those are > loaded at boot and these routines read back from the chips. > > I think it prints error messages if the chips don't respond though.. Need > to check that but I am out with family at the moment. > > Chris > > > On Mon, Feb 5, 2024, 17:05 Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> BTW, I don't if I ever said this (if so, just a remnider): >> >> Before you generate code from HalCoGen, you MUST put the code that is in >> CCS back in the place where HalCoGen puts its code. That is because there >> are a few places where I put some stuff in the "USER CODE BEGIN" section. >> Look in particular at sys_main.c and spi.c (in which I actually commented >> out a whole bunch of code and put in my own version in hcgExtras). >> >> I run CCS on Linux and HCG on Windows, and use dropbox to connect them. >> HalCoGen writes directly into DropBox. Then I just copy all the files on >> the Linux side from dropbox into CCS, and if I make any changes in the USER >> CODE section then I copy it from CCS back to HCG. >> >> I'm not sure what you meant about HCG a few mails back. The HalCoGen >> file PACSatBlinky.hcg certainly is set up for the TMS570LS0914. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Mon, Feb 5, 2024 at 4:56 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> Just realized that the second temp sensor is not on this board. I took >>> it off to change address and have not put it back yet. Probably will work >>> fine. >>> ------------------------------ >>> *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> >>> *Sent:* Monday, February 5, 2024 3:53 PM >>> *To:* Bob Stricklin <bstrick(a)n5brg.com> >>> *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> >>> *Subject:* [pacsat-dev] Re: One board now talking >>> >>> Oh, I see. So this is saying that I2c in general is ok, but that the >>> temp sensor near the CPU is not working for whatever reason (bad bus >>> connection, bad address bit connection, or bad chip). >>> >>> And regarding the MRAM, I have the chip select wrong on at least one of >>> those MRAM devices. I just found that earlier and did not push it up to >>> the repository.. Let me check what else I have done since I pushed >>> upstream, and if all is ok, I'll push this change too. Looks like most >>> everything in the MRAM is ok otheriwise (whew! Was driving me crazy) >>> >>> I see you sent something else. Have not seen it yet but will send this. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Mon, Feb 5, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>> wrote: >>> >>> Ok, looks like two of the MRAMs are ok, and two are not for whatever >>> reason. Oh, I bet I know...I think I got the chip select lines wrong on >>> one or two of them. Funny the temp actually looks ok despite the error. >>> In the middle of checking something else. Will get back after a bit more >>> testing. >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>> Pacsat> >>> Pacsat>get mram sr >>> MRAM0: status 32, MRAM1: status ff >>> MRAM2: status 2, MRAM3: status ff >>> Pacsat>get temp >>> CPU Temp request failed >>> Transmitter temp: 99 ( 29.5 degrees C) >>> Pacsat> >>> >>> >>> ------------------------------ >>> *From:* Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>> *Sent:* Monday, February 5, 2024 3:35 PM >>> *To:* Bob Stricklin <bstrick(a)n5brg.com> >>> *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> >>> *Subject:* Re: [pacsat-dev] One board now talking >>> >>> Oh, I just sent you a mail before seeing this. >>> >>> Wow! Looks like there may be something wrong with my board. Could you >>> do "get mram sr" please? You could try "get temp" also. >>> >>> I'm not sure if those are the right values for the DCT (the AX5043). I >>> know I had a quick way at one point that I could tell if one particular >>> register was correct. I'll see if I can find it. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>> After getting TX and RX connected correctly now working. Do not know >>> what the correct report back is but here is some checks... >>> >>> This board has four 4Mb MRAMs installed. >>> >>> >>> Pacsat>get version >>> >>> AMSAT-NA PacSat Console >>> Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) >>> Compiled *RELEASE* >>> **X, E, U, or DEBUG Version: Not configured for flight** >>> Watchdog NOT Enabled >>> Using FreeRTOS withOUT premption enabled; >>> Free heap size is 75504 >>> Flash memory size 1Mb+0Kb >>> MRAM config data partition size=1008, file system size=1047568 >>> Pacsat>>get version >>> >>> AMSAT-NA PacSat Console >>> Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) >>> Compiled *RELEASE* >>> **X, E, U, or DEBUG Version: Not configured for flight** >>> Watchdog NOT Enabled >>> Using FreeRTOS withOUT premption enabled; >>> Free heap size is 75504 >>> Flash memory size 1Mb+0Kb >>> MRAM config data partition size=1008, file system size=1047568 >>> Pacsat> >>> >>> Pacsat>get RSSI >>> RSSI is -64 dBm >>> Pacsat> >>> >>> Pacsat>get ax >>> AX5043 dev 1 TX: >>> FIFOSTAT: 00 >>> PWRMODE:: 77 >>> XTALCAP: 119 >>> PLLLOOP: 77 >>> PLLCPI: 77 >>> PLLVCOI: 77 >>> PLLRANGINGA: 77 >>> PLLVCODIV: 77 >>> FREQ 1911466666 Hz >>> MODULATION: 77 >>> TXPWRCOEFFB0: 77 >>> TXPWRCOEFFB1: 77 >>> >>> AX5043 dev 0 RX: >>> FIFOSTAT: 00 >>> PWRMODE: 67 >>> XTALCAP: 103 >>> PLLLOOP: 67 >>> PLLCPI: 67 >>> PLLVCOI: 67 >>> PLLRANGINGA: 67 >>> PLLVCODIV: 67 >>> FREQ 1654462744 Hz >>> MODULATION: 67 >>> TXPWRCOEFFB0: 67 >>> TXPWRCOEFFB1: 67 >>> Pacsat> >>> >>> >>> >>> >>> ----------------------------------------------------------- >>> >>> 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 >> > > ----------------------------------------------------------- > > 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: One board now talking
by Chris Thompson 05 Feb '24

05 Feb '24

Looks promising but the radio chips have the wrong frequencies. Those are loaded at boot and these routines read back from the chips. I think it prints error messages if the chips don't respond though.. Need to check that but I am out with family at the moment. Chris On Mon, Feb 5, 2024, 17:05 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > BTW, I don't if I ever said this (if so, just a remnider): > > Before you generate code from HalCoGen, you MUST put the code that is in > CCS back in the place where HalCoGen puts its code. That is because there > are a few places where I put some stuff in the "USER CODE BEGIN" section. > Look in particular at sys_main.c and spi.c (in which I actually commented > out a whole bunch of code and put in my own version in hcgExtras). > > I run CCS on Linux and HCG on Windows, and use dropbox to connect them. > HalCoGen writes directly into DropBox. Then I just copy all the files on > the Linux side from dropbox into CCS, and if I make any changes in the USER > CODE section then I copy it from CCS back to HCG. > > I'm not sure what you meant about HCG a few mails back. The HalCoGen file > PACSatBlinky.hcg certainly is set up for the TMS570LS0914. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:56 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Just realized that the second temp sensor is not on this board. I took it >> off to change address and have not put it back yet. Probably will work fine. >> ------------------------------ >> *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> >> *Sent:* Monday, February 5, 2024 3:53 PM >> *To:* Bob Stricklin <bstrick(a)n5brg.com> >> *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> >> *Subject:* [pacsat-dev] Re: One board now talking >> >> Oh, I see. So this is saying that I2c in general is ok, but that the >> temp sensor near the CPU is not working for whatever reason (bad bus >> connection, bad address bit connection, or bad chip). >> >> And regarding the MRAM, I have the chip select wrong on at least one of >> those MRAM devices. I just found that earlier and did not push it up to >> the repository.. Let me check what else I have done since I pushed >> upstream, and if all is ok, I'll push this change too. Looks like most >> everything in the MRAM is ok otheriwise (whew! Was driving me crazy) >> >> I see you sent something else. Have not seen it yet but will send this. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Mon, Feb 5, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >> Ok, looks like two of the MRAMs are ok, and two are not for whatever >> reason. Oh, I bet I know...I think I got the chip select lines wrong on >> one or two of them. Funny the temp actually looks ok despite the error. >> In the middle of checking something else. Will get back after a bit more >> testing. >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> Pacsat> >> Pacsat>get mram sr >> MRAM0: status 32, MRAM1: status ff >> MRAM2: status 2, MRAM3: status ff >> Pacsat>get temp >> CPU Temp request failed >> Transmitter temp: 99 ( 29.5 degrees C) >> Pacsat> >> >> >> ------------------------------ >> *From:* Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> *Sent:* Monday, February 5, 2024 3:35 PM >> *To:* Bob Stricklin <bstrick(a)n5brg.com> >> *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> >> *Subject:* Re: [pacsat-dev] One board now talking >> >> Oh, I just sent you a mail before seeing this. >> >> Wow! Looks like there may be something wrong with my board. Could you >> do "get mram sr" please? You could try "get temp" also. >> >> I'm not sure if those are the right values for the DCT (the AX5043). I >> know I had a quick way at one point that I could tell if one particular >> register was correct. I'll see if I can find it. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> After getting TX and RX connected correctly now working. Do not know what >> the correct report back is but here is some checks... >> >> This board has four 4Mb MRAMs installed. >> >> >> Pacsat>get version >> >> AMSAT-NA PacSat Console >> Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) >> Compiled *RELEASE* >> **X, E, U, or DEBUG Version: Not configured for flight** >> Watchdog NOT Enabled >> Using FreeRTOS withOUT premption enabled; >> Free heap size is 75504 >> Flash memory size 1Mb+0Kb >> MRAM config data partition size=1008, file system size=1047568 >> Pacsat>>get version >> >> AMSAT-NA PacSat Console >> Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) >> Compiled *RELEASE* >> **X, E, U, or DEBUG Version: Not configured for flight** >> Watchdog NOT Enabled >> Using FreeRTOS withOUT premption enabled; >> Free heap size is 75504 >> Flash memory size 1Mb+0Kb >> MRAM config data partition size=1008, file system size=1047568 >> Pacsat> >> >> Pacsat>get RSSI >> RSSI is -64 dBm >> Pacsat> >> >> Pacsat>get ax >> AX5043 dev 1 TX: >> FIFOSTAT: 00 >> PWRMODE:: 77 >> XTALCAP: 119 >> PLLLOOP: 77 >> PLLCPI: 77 >> PLLVCOI: 77 >> PLLRANGINGA: 77 >> PLLVCODIV: 77 >> FREQ 1911466666 Hz >> MODULATION: 77 >> TXPWRCOEFFB0: 77 >> TXPWRCOEFFB1: 77 >> >> AX5043 dev 0 RX: >> FIFOSTAT: 00 >> PWRMODE: 67 >> XTALCAP: 103 >> PLLLOOP: 67 >> PLLCPI: 67 >> PLLVCOI: 67 >> PLLRANGINGA: 67 >> PLLVCODIV: 67 >> FREQ 1654462744 Hz >> MODULATION: 67 >> TXPWRCOEFFB0: 67 >> TXPWRCOEFFB1: 67 >> Pacsat> >> >> >> >> >> ----------------------------------------------------------- >> >> 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: One board now talking
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

BTW, I don't if I ever said this (if so, just a remnider): Before you generate code from HalCoGen, you MUST put the code that is in CCS back in the place where HalCoGen puts its code. That is because there are a few places where I put some stuff in the "USER CODE BEGIN" section. Look in particular at sys_main.c and spi.c (in which I actually commented out a whole bunch of code and put in my own version in hcgExtras). I run CCS on Linux and HCG on Windows, and use dropbox to connect them. HalCoGen writes directly into DropBox. Then I just copy all the files on the Linux side from dropbox into CCS, and if I make any changes in the USER CODE section then I copy it from CCS back to HCG. I'm not sure what you meant about HCG a few mails back. The HalCoGen file PACSatBlinky.hcg certainly is set up for the TMS570LS0914. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 4:56 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Just realized that the second temp sensor is not on this board. I took it > off to change address and have not put it back yet. Probably will work fine. > ------------------------------ > *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Monday, February 5, 2024 3:53 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: One board now talking > > Oh, I see. So this is saying that I2c in general is ok, but that the temp > sensor near the CPU is not working for whatever reason (bad bus connection, > bad address bit connection, or bad chip). > > And regarding the MRAM, I have the chip select wrong on at least one of > those MRAM devices. I just found that earlier and did not push it up to > the repository.. Let me check what else I have done since I pushed > upstream, and if all is ok, I'll push this change too. Looks like most > everything in the MRAM is ok otheriwise (whew! Was driving me crazy) > > I see you sent something else. Have not seen it yet but will send this. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > > Ok, looks like two of the MRAMs are ok, and two are not for whatever > reason. Oh, I bet I know...I think I got the chip select lines wrong on > one or two of them. Funny the temp actually looks ok despite the error. > In the middle of checking something else. Will get back after a bit more > testing. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Pacsat> > Pacsat>get mram sr > MRAM0: status 32, MRAM1: status ff > MRAM2: status 2, MRAM3: status ff > Pacsat>get temp > CPU Temp request failed > Transmitter temp: 99 ( 29.5 degrees C) > Pacsat> > > > ------------------------------ > *From:* Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > *Sent:* Monday, February 5, 2024 3:35 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> > *Subject:* Re: [pacsat-dev] One board now talking > > Oh, I just sent you a mail before seeing this. > > Wow! Looks like there may be something wrong with my board. Could you do > "get mram sr" please? You could try "get temp" also. > > I'm not sure if those are the right values for the DCT (the AX5043). I > know I had a quick way at one point that I could tell if one particular > register was correct. I'll see if I can find it. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > After getting TX and RX connected correctly now working. Do not know what > the correct report back is but here is some checks... > > This board has four 4Mb MRAMs installed. > > > Pacsat>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat>>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat> > > Pacsat>get RSSI > RSSI is -64 dBm > Pacsat> > > Pacsat>get ax > AX5043 dev 1 TX: > FIFOSTAT: 00 > PWRMODE:: 77 > XTALCAP: 119 > PLLLOOP: 77 > PLLCPI: 77 > PLLVCOI: 77 > PLLRANGINGA: 77 > PLLVCODIV: 77 > FREQ 1911466666 Hz > MODULATION: 77 > TXPWRCOEFFB0: 77 > TXPWRCOEFFB1: 77 > > AX5043 dev 0 RX: > FIFOSTAT: 00 > PWRMODE: 67 > XTALCAP: 103 > PLLLOOP: 67 > PLLCPI: 67 > PLLVCOI: 67 > PLLRANGINGA: 67 > PLLVCODIV: 67 > FREQ 1654462744 Hz > MODULATION: 67 > TXPWRCOEFFB0: 67 > TXPWRCOEFFB1: 67 > Pacsat> > > > > > ----------------------------------------------------------- > > 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: One board now talking
by Bob Stricklin 05 Feb '24

05 Feb '24

Just realized that the second temp sensor is not on this board. I took it off to change address and have not put it back yet. Probably will work fine. ________________________________ From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, February 5, 2024 3:53 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Bill via pacsat-dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: One board now talking Oh, I see. So this is saying that I2c in general is ok, but that the temp sensor near the CPU is not working for whatever reason (bad bus connection, bad address bit connection, or bad chip). And regarding the MRAM, I have the chip select wrong on at least one of those MRAM devices. I just found that earlier and did not push it up to the repository.. Let me check what else I have done since I pushed upstream, and if all is ok, I'll push this change too. Looks like most everything in the MRAM is ok otheriwise (whew! Was driving me crazy) I see you sent something else. Have not seen it yet but will send this. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Ok, looks like two of the MRAMs are ok, and two are not for whatever reason. Oh, I bet I know...I think I got the chip select lines wrong on one or two of them. Funny the temp actually looks ok despite the error. In the middle of checking something else. Will get back after a bit more testing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Pacsat> Pacsat>get mram sr MRAM0: status 32, MRAM1: status ff MRAM2: status 2, MRAM3: status ff Pacsat>get temp CPU Temp request failed Transmitter temp: 99 ( 29.5 degrees C) Pacsat> ________________________________ From: Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> Sent: Monday, February 5, 2024 3:35 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Bill via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: Re: [pacsat-dev] One board now talking Oh, I just sent you a mail before seeing this. Wow! Looks like there may be something wrong with my board. Could you do "get mram sr" please? You could try "get temp" also. I'm not sure if those are the right values for the DCT (the AX5043). I know I had a quick way at one point that I could tell if one particular register was correct. I'll see if I can find it. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: After getting TX and RX connected correctly now working. Do not know what the correct report back is but here is some checks... This board has four 4Mb MRAMs installed. Pacsat>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat>>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat> Pacsat>get RSSI RSSI is -64 dBm Pacsat> Pacsat>get ax AX5043 dev 1 TX: FIFOSTAT: 00 PWRMODE:: 77 XTALCAP: 119 PLLLOOP: 77 PLLCPI: 77 PLLVCOI: 77 PLLRANGINGA: 77 PLLVCODIV: 77 FREQ 1911466666 Hz MODULATION: 77 TXPWRCOEFFB0: 77 TXPWRCOEFFB1: 77 AX5043 dev 0 RX: FIFOSTAT: 00 PWRMODE: 67 XTALCAP: 103 PLLLOOP: 67 PLLCPI: 67 PLLVCOI: 67 PLLRANGINGA: 67 PLLVCODIV: 67 FREQ 1654462744 Hz MODULATION: 67 TXPWRCOEFFB0: 67 TXPWRCOEFFB1: 67 Pacsat> ----------------------------------------------------------- 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 ----------------------------------------------------------- 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