- pacsat-dev - mailman.amsat.org

Re: Quick test for AX5043
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > [image: IMG_0004] > > > I see version is q so I think this is most current. Not seeing 4 chips > yet. > > Bob > > On Feb 8, 2024, at 4:01 PM, Burns > > > Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > > Ok, please also get X0.1q (just pushed upstream). > > I may have said before that I got one MRAM to work on my board. Now I > have changed a few things so that it seems to do at least some of the tests > correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if > it will work with yours as well. But anyway, it is an improvement. Do > "clear mram" first. > > > Pacsat>get mram sr > MRAM0: status ff, MRAM1: status 32 > MRAM2: status ff, MRAM3: status ff > > Pacsat>clear mram > Post Launch Time Set to 2 minutesSet to start in safe mode > WOD Frequency,size set to Default, and WOD Indices initialized > Telemetry min/max in MRAM initialized > Reset Count set to 0 > Nonfatal error count zeroed (TBD) > CRC calculated for init code and full code (TBD) > MRAM Version Number Initialized > MRAM config partition size is 1008 bytes > MRAM file partition 1 size is 523280 > > Pacsat>get mram size > MRAM Address Size=3 > Partition 0 size=1008, partition 1=523280 > MRAM0 size is 0KBytes, MRAM1 size is 512KBytes > MRAM2 size is 0KBytes, MRAM3 size is 0KBytes > Pacsat>test mram 4 42 > NOTE: This test will wipe out the file system and configuration values in > MRAM. > > Testing with read/write size = 4 bytes, random value base is 0x1864 > Write starting at 0KB > Write starting at 16KB > Write starting at 32KB > Write starting at 48KB > Write starting at 64KB > Write starting at 80KB > <skipping a bunch of additional writes> > Read starting at 0KB > Read starting at 16KB > Read starting at 32KB > Read starting at 48KB > Read starting at 64KB > Read starting at 80KB > Read starting at 96KB > Read starting at 112KB > Read starting at 128KB > <...> > Read starting at 432KB > Read starting at 448KB > Read starting at 464KB > Read starting at 480KB > Read starting at 496KB > Read starting at 512KB > Test is ok! Time is 37 seconds > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Ok Burns. Will check soon. At the gym and will be home in about 30 >> minutes. >> >> Good that you fixed this. >> >> I added 20k pull-up on MOSI and security chip. Also moved the enable >> lines on the two supply control chips will give details on that later. >> >> Bob >> >> On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> >> I got one MRAM working, specifically #1. I apparently fixed the chip >> select for that one. >> >> Please try "get mram sr" with X0.1p. If they say something other than >> 0xff, they are probably working. Don't mess with the other MRAM commands >> unless it sees all the MRAMs. I think a lot of that code assumes there are >> 4 good MRAMs. >> >> In the meantime, I now KNOW that most the SPI bus is ~good on my board, >> so I'll focus a bit more on the chip selects for 0 and 2. If I have time, >> I'll see if I can get some of the other tests working for only some MRAMs. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> Ok, Bob, glad you figured out how to get the new code. >>> >>> Regarding the MRAM. I at first thought that you said "okay", but now I >>> think you said zero K. I originally set up the MRAM code to figure out >>> the size of the MRAMs, whether they needed 2 or 3 address bytes, and how >>> many were present. But I only had the one example of Jim's launchpad >>> board, so I'm not surprised it is not quite right for larger MRAMs and >>> especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and >>> 3 do not). But since none work on my board, I could not do anything more. >>> As soon as I can get a board with working MRAMs, I'll fix all that. Also >>> with all the MRAM errors that I get I have disabled a number of the tasks >>> because they quickly failed and reset the processor. I'll fix that when I >>> get a working MRAM board. >>> >>> Regarding the 5043: Did you do "test ax"? That shows a couple >>> registers from each of the 5043s which we know the value of. I think you >>> can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did >>> not display all 5 just because I did not know the correct values anyway, >>> and it would just run off the bottom of the screen :-) >>> >>> More in a separate mailing. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> 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 >>>> >>>> <Screenshot from 2024-02-08 02-56-00.png> >>>> >>>> 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> >>>> 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> >>>> 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> wrote: >>>>> >>>>> OK >>>>> >>>>> Bob >>>>> >>>>> On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev < >>>>> pacsat-dev(a)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> >>>>> 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 >>>>> 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 > > > ----------------------------------------------------------- > > 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: Quick test for AX5043
by Bob Stricklin 08 Feb '24

08 Feb '24

[IMG_0004] I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I got one MRAM working, specifically #1. I apparently fixed the chip select for that one. Please try "get mram sr" with X0.1p. If they say something other than 0xff, they are probably working. Don't mess with the other MRAM commands unless it sees all the MRAMs. I think a lot of that code assumes there are 4 good MRAMs. In the meantime, I now KNOW that most the SPI bus is ~good on my board, so I'll focus a bit more on the chip selects for 0 and 2. If I have time, I'll see if I can get some of the other tests working for only some MRAMs. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Ok, Bob, glad you figured out how to get the new code. Regarding the MRAM. I at first thought that you said "okay", but now I think you said zero K. I originally set up the MRAM code to figure out the size of the MRAMs, whether they needed 2 or 3 address bytes, and how many were present. But I only had the one example of Jim's launchpad board, so I'm not surprised it is not quite right for larger MRAMs and especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and 3 do not). But since none work on my board, I could not do anything more. As soon as I can get a board with working MRAMs, I'll fix all that. Also with all the MRAM errors that I get I have disabled a number of the tasks because they quickly failed and reset the processor. I'll fix that when I get a working MRAM board. Regarding the 5043: Did you do "test ax"? That shows a couple registers from each of the 5043s which we know the value of. I think you can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not display all 5 just because I did not know the correct values anyway, and it would just run off the bottom of the screen :-) More in a separate mailing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: 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 <Screenshot from 2024-02-08 02-56-00.png> 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/> ----------------------------------------------------------- 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 ----------------------------------------------------------- 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 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: Quick test for AX5043
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Ok Burns. Will check soon. At the gym and will be home in about 30 > minutes. > > Good that you fixed this. > > I added 20k pull-up on MOSI and security chip. Also moved the enable lines > on the two supply control chips will give details on that later. > > Bob > > On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > > I got one MRAM working, specifically #1. I apparently fixed the chip > select for that one. > > Please try "get mram sr" with X0.1p. If they say something other than > 0xff, they are probably working. Don't mess with the other MRAM commands > unless it sees all the MRAMs. I think a lot of that code assumes there are > 4 good MRAMs. > > In the meantime, I now KNOW that most the SPI bus is ~good on my board, so > I'll focus a bit more on the chip selects for 0 and 2. If I have time, > I'll see if I can get some of the other tests working for only some MRAMs. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> Ok, Bob, glad you figured out how to get the new code. >> >> Regarding the MRAM. I at first thought that you said "okay", but now I >> think you said zero K. I originally set up the MRAM code to figure out >> the size of the MRAMs, whether they needed 2 or 3 address bytes, and how >> many were present. But I only had the one example of Jim's launchpad >> board, so I'm not surprised it is not quite right for larger MRAMs and >> especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and >> 3 do not). But since none work on my board, I could not do anything more. >> As soon as I can get a board with working MRAMs, I'll fix all that. Also >> with all the MRAM errors that I get I have disabled a number of the tasks >> because they quickly failed and reset the processor. I'll fix that when I >> get a working MRAM board. >> >> Regarding the 5043: Did you do "test ax"? That shows a couple registers >> from each of the 5043s which we know the value of. I think you can say >> "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not >> display all 5 just because I did not know the correct values anyway, and it >> would just run off the bottom of the screen :-) >> >> More in a separate mailing. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> 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 >>> >>> <Screenshot from 2024-02-08 02-56-00.png> >>> >>> 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> >>> 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> 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> wrote: >>>> >>>> OK >>>> >>>> Bob >>>> >>>> On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev < >>>> pacsat-dev(a)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> >>>> 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 >>>> 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: Quick test for AX5043
by Bob Stricklin 08 Feb '24

08 Feb '24

Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: I got one MRAM working, specifically #1. I apparently fixed the chip select for that one. Please try "get mram sr" with X0.1p. If they say something other than 0xff, they are probably working. Don't mess with the other MRAM commands unless it sees all the MRAMs. I think a lot of that code assumes there are 4 good MRAMs. In the meantime, I now KNOW that most the SPI bus is ~good on my board, so I'll focus a bit more on the chip selects for 0 and 2. If I have time, I'll see if I can get some of the other tests working for only some MRAMs. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Ok, Bob, glad you figured out how to get the new code. Regarding the MRAM. I at first thought that you said "okay", but now I think you said zero K. I originally set up the MRAM code to figure out the size of the MRAMs, whether they needed 2 or 3 address bytes, and how many were present. But I only had the one example of Jim's launchpad board, so I'm not surprised it is not quite right for larger MRAMs and especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and 3 do not). But since none work on my board, I could not do anything more. As soon as I can get a board with working MRAMs, I'll fix all that. Also with all the MRAM errors that I get I have disabled a number of the tasks because they quickly failed and reset the processor. I'll fix that when I get a working MRAM board. Regarding the 5043: Did you do "test ax"? That shows a couple registers from each of the 5043s which we know the value of. I think you can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not display all 5 just because I did not know the correct values anyway, and it would just run off the bottom of the screen :-) More in a separate mailing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: 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 <Screenshot from 2024-02-08 02-56-00.png> 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/> ----------------------------------------------------------- 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 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: Quick test for AX5043
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

Ok, Bob, glad you figured out how to get the new code. Regarding the MRAM. I at first thought that you said "okay", but now I think you said zero K. I originally set up the MRAM code to figure out the size of the MRAMs, whether they needed 2 or 3 address bytes, and how many were present. But I only had the one example of Jim's launchpad board, so I'm not surprised it is not quite right for larger MRAMs and especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and 3 do not). But since none work on my board, I could not do anything more. As soon as I can get a board with working MRAMs, I'll fix all that. Also with all the MRAM errors that I get I have disabled a number of the tasks because they quickly failed and reset the processor. I'll fix that when I get a working MRAM board. Regarding the 5043: Did you do "test ax"? That shows a couple registers from each of the 5043s which we know the value of. I think you can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not display all 5 just because I did not know the correct values anyway, and it would just run off the bottom of the screen :-) More in a separate mailing. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > 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 > > > 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> 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> 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> wrote: >> >> OK >> >> Bob >> >> On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)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> >> 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 >> 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 1

Pacsat dev meeting 2/8/2024
by Bill 08 Feb '24

08 Feb '24

Pacsat dev meeting 2/8/2024 Thu, Feb 8, 2024 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/360322877 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3412 - One-touch: tel:+18722403412,,360322877# Access Code: 360-322-877 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 360 322 877 Or dial directly: 360322877(a)67.217.95.2 or 67.217.95.2##360322877 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Fwd: Pacsat Budget
by Bill Reed 08 Feb '24

08 Feb '24

FYI. We will discuss this evening. Bill -------- Forwarded Message -------- Subject: Re: Pacsat Budget Date: Thu, 8 Feb 2024 14:14:49 -0600 From: Bill Reed <bill(a)brconnect.com> To: Jerry Buxton <vpe(a)amsat.us> CC: Zach Metzinger <zmetzing(a)pobox.com> Jerry, Thanks for managing this. The 2024 Pacsat budget that I submitted fully implements the current year activities for the Pacsat program just as Jonathan and I defined it nearly two years ago. Your support of my budget will help us complete Phase I of the Pacsat program and begin the implementation of Phase II and beyond. I hope the details that I provided in the budget were sufficient. If not, please feel free to call out to me for more information. We are making good progress with our testing of the prototype pacsat cards that were built last December. Many of the issues that we have found turned out to be software issues. At this point the hardware issues include the power supply chip and possibly some of the traces for the MRAM chips. We will probably do a second prototype run in the next 60 to 90 days. I am concerned that the budget approval has been delayed. We have some immediate expenses ( mostly shipping and some parts ) that need funding and I am wondering if you would support an interim funding of approx $200 for these expenses. When we receive full budget allocation then we can move forward as planned. Bill. On 2/7/2024 11:40 PM, Jerry Buxton wrote: > On 2/7/2024 12:50, Bill Reed wrote: >> Thanks for getting the 2024 pacsat budget approved. >> >> Bill >> > Hi Bill, > > Not officially approved yet, but getting close as we discussed the > various Engineering "buckets" last night on the monthly BOD/SO meeting. > From the meeting last night I need to provide some more detail on a > variety of the categories, to satisfy the President's presentation of > the budget to the BOD. > Too, we're going to have some changes to the GOLF budget due to ADCS > upgrades so I'm not sure if we'll need that in order to approve, > anyway I do not have numbers yet since we just made the decision to > change and have to work with the vendor. > > The intention of the President is for me to have the requested > detail/breakdown provided in the next week or two and then the BOD > will be presented with the budget to be voted on or approved. Stay > tuned, things are progressing just not quite there yet! > > Jerry Buxton, NØJY > Vice President - Engineering > Radio Amateur Satellite Corp. > (AMSAT) > >

1 0

Please try MRAM with X0.1p
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

New version up there. Two MRAM chip selects were set wrong in HCG. (I had read the port number wrong a week or so ago and fixed the code, but not HCG. Please try the MRAMs again with this new version, Bob. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

I won't be there tonight. Current report
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

As usual, I will not be at the 2nd Thursday meeting. Here is where I am: -The OS is running (a timer is flashing the lights, not to mention all the drives mentioned below depend on interrupts and OS semaphores -The low level SPI bus software to read/write the AX5043s appears to be working, along with the very basic test commands -The I2c access to the thermometers appears to be working along with the test command to read them. -The SPI bus to read and write the MRAM may be working. Bob seems to have access to two of the four MRAMs on his board. However, with the same software, I can access none of the ones on my board. I'm pretty sure there is one broken trace where I can measure it (to an intentionally missing MRAM), but that does not explain the other 3. I'm also not sure about the test and setup code for the MRAM. Bob seems to have some problems with the two of his that are working. The two not working could be software or hardware. I can't tell from a distance, but will look further when I get a board that even two MRAMs work on. Just to be clear on what I can and will do: I know it was mostly my doing that got the busses working and put in the test code, so I want to make that all happen, in particular checking out the MRAMs. I'm also reasonably good at finding crashes and OS problems, so I'll make sure that all works. I have also removed even more code that was useful only for Golf and there are probably some commands which do nothing which I can also remove. Please note that there is NOTHING in this code that is ITAR related despite it having come originally from Golf. I have already added a number parameter to the routines that access the 5043 since there are more of them now. However, I really have to get back to Golf and Fox+ and there are a lot of things that are just not in my baliwick, largely having to do with the details of sending and receiving and using the higher level 5043 routines. I'm assuming that Jim and Chris will carry on once I get the hardware access working. For example, there are several commands that would probably be useful, but which I'm don't feel competent to work on. The ones that I think of are as follows (I may not have them exactly right): test pll -- this sweeps the frequency setting for one of the receive (2m) 5043 to ensure that it can lock on. This fails when the wrong (or no) inductor is present. It should probably be fixed to do each individual Rx, and maybe the Tx (although 70cm does not need an inductor). test rx -- This actually transmits on the receive frequency using the receive 5043. The purpose is to allow us to find the correct frequency setting for receive by watching what frequency it transmits on. (Putting the exact number into the 5043 never gave the exact frequency so this lets us tweak the receive frequency to be "exact".) I'm not sure if it is possible to do this with the blinky board, but if it is useful, that needs to be changed to be able to specify the specific Rx chip. And of course the actual packet code which I don't plan to touch :-) 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 1

Re: I won't be there tonight. Current report
by Corey Minyard 08 Feb '24

08 Feb '24

This sounds like great progress. I won't be able to make it tonight, I have to take my daughter to a doctor's appointment. -corey On Thu, Feb 8, 2024 at 8:30 AM Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > As usual, I will not be at the 2nd Thursday meeting. Here is where I am: > > -The OS is running (a timer is flashing the lights, not to mention all the drives mentioned below depend on interrupts and OS semaphores > -The low level SPI bus software to read/write the AX5043s appears to be working, along with the very basic test commands > -The I2c access to the thermometers appears to be working along with the test command to read them. > -The SPI bus to read and write the MRAM may be working. Bob seems to have access to two of the four MRAMs on his board. However, with the same software, I can access none of the ones on my board. I'm pretty sure there is one broken trace where I can measure it (to an intentionally missing MRAM), but that does not explain the other 3. I'm also not sure about the test and setup code for the MRAM. Bob seems to have some problems with the two of his that are working. The two not working could be software or hardware. I can't tell from a distance, but will look further when I get a board that even two MRAMs work on. > > Just to be clear on what I can and will do: I know it was mostly my doing that got the busses working and put in the test code, so I want to make that all happen, in particular checking out the MRAMs. I'm also reasonably good at finding crashes and OS problems, so I'll make sure that all works. I have also removed even more code that was useful only for Golf and there are probably some commands which do nothing which I can also remove. Please note that there is NOTHING in this code that is ITAR related despite it having come originally from Golf. > > I have already added a number parameter to the routines that access the 5043 since there are more of them now. However, I really have to get back to Golf and Fox+ and there are a lot of things that are just not in my baliwick, largely having to do with the details of sending and receiving and using the higher level 5043 routines. I'm assuming that Jim and Chris will carry on once I get the hardware access working. For example, there are several commands that would probably be useful, but which I'm don't feel competent to work on. The ones that I think of are as follows (I may not have them exactly right): > > test pll -- this sweeps the frequency setting for one of the receive (2m) 5043 to ensure that it can lock on. This fails when the wrong (or no) inductor is present. It should probably be fixed to do each individual Rx, and maybe the Tx (although 70cm does not need an inductor). > > test rx -- This actually transmits on the receive frequency using the receive 5043. The purpose is to allow us to find the correct frequency setting for receive by watching what frequency it transmits on. (Putting the exact number into the 5043 never gave the exact frequency so this lets us tweak the receive frequency to be "exact".) I'm not sure if it is possible to do this with the blinky board, but if it is useful, that needs to be changed to be able to specify the specific Rx chip. > > And of course the actual packet code which I don't plan to touch :-) > 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