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

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/[email protected] >>>> 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/[email protected] >>> 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/[email protected] > 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/[email protected] > 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:[email protected]>> 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:[email protected]>> 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:[email protected]>> 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:[email protected]>> 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:[email protected]>> wrote: OK Bob On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> 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:[email protected]>> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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/[email protected] 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/[email protected] >> 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/[email protected] > 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/[email protected] > 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

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:[email protected]] 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:[email protected]>> 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:[email protected]>> 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:[email protected]>> wrote: OK Bob On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> 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:[email protected]>> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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/[email protected] >>>> 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/[email protected] > 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/[email protected] > 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