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

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

08 Feb '24

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

1 0

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

08 Feb '24

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

2 2

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

07 Feb '24

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

1 0

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

06 Feb '24

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

1 1

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

05 Feb '24

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

05 Feb '24

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

05 Feb '24

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

05 Feb '24

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

1 0

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

05 Feb '24

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

Re: One board now talking
by Bob Stricklin 05 Feb '24

05 Feb '24

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

1 0

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

05 Feb '24

Oh, I just sent you a mail before seeing this. Wow! Looks like there may be something wrong with my board. Could you do "get mram sr" please? You could try "get temp" also. I'm not sure if those are the right values for the DCT (the AX5043). I know I had a quick way at one point that I could tell if one particular register was correct. I'll see if I can find it. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > After getting TX and RX connected correctly now working. Do not know what > the correct report back is but here is some checks... > > This board has four 4Mb MRAMs installed. > > > Pacsat>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat>>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat> > > Pacsat>get RSSI > RSSI is -64 dBm > Pacsat> > > Pacsat>get ax > AX5043 dev 1 TX: > FIFOSTAT: 00 > PWRMODE:: 77 > XTALCAP: 119 > PLLLOOP: 77 > PLLCPI: 77 > PLLVCOI: 77 > PLLRANGINGA: 77 > PLLVCODIV: 77 > FREQ 1911466666 Hz > MODULATION: 77 > TXPWRCOEFFB0: 77 > TXPWRCOEFFB1: 77 > > AX5043 dev 0 RX: > FIFOSTAT: 00 > PWRMODE: 67 > XTALCAP: 103 > PLLLOOP: 67 > PLLCPI: 67 > PLLVCOI: 67 > PLLRANGINGA: 67 > PLLVCODIV: 67 > FREQ 1654462744 Hz > MODULATION: 67 > TXPWRCOEFFB0: 67 > TXPWRCOEFFB1: 67 > Pacsat> > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[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 >

2 1

Re: Small bugs to fix (I think)
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

Bob, When you say "The Blinky Version" you mean the branch "WB1FJ_Port_to_Blinky"? What are you using for a serial port adapter. Mine looks like a slightly big USB-A plug with a cable that has 4 conductors: Red, Black, Green, White. I have the red one taped back since that is +5V from the computer. Black is of course ground, White is Rx relative to the adapter, but it goes to the Tx output (5th pin in), and green in Tx relative to the adapter but goes to the Rx input on the board (4th pin in from the right on the back with the PC104 facing me but at the furthest edge. I'm not going to try to figure out the pin numbers :-) At this point, I've switched the software around so all of those bus lines act as GPIOs and then just have a bit at the beginning of the program that switches them on and off one at a time. Clock and MOSI seem ok all the way up to U79 (the only place I could solder on jumpers to hook my meter/scope to). We know that SOMI was not ok at U79, but I'm not totally convinced it is ok on the others either. I tried to measure to the little via beside U78 and it did not look right. (Hard as heck to do it though so I could be wrong.). I may give up on the MRAM for the moment and look at the DCTs. At least I can easily get at those bus and NCS connections. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 2:20 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I managed to get the repository into CCS and have tried the Blinky version > but still not working for me. I think the board is working but my issue is > with the serial interface cable or the terminal program. I backed away from > it for a while to work on some other things. Will sort things out later. > > Also got the Memory version but that one gives me a error message with the > programmer and I have not figured out why on this either. Proper programmer > is selected. > > Bob > > > On Feb 5, 2024, at 10:53 AM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I finally got some wires soldered to the MRAM SPI bus (what a pain! > PLEASE put these on some pins for debugging on the next one!) One thing > that seems to be happening is that the CLK line is pulled down. I think it > should be high. There is a check box for "clock polarity" in HCG, but it > is not checked...same as Golf. I'll play more this afternoon. > > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Sun, Feb 4, 2024 at 1:30 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> Hi Bob, >> >> I don't have long today, but I with your diagram, I was able to see that >> there was apparently a via just to the left of U76 for that pin, so I was >> able to measure continuity to there from the CPU pin 94 (and just to be >> sure I had the right one I could identify the via just below the processor >> and measured to that. So what this seems to say is that there is some >> issue with the trace between U79 pin 2 and U76 pin 2. That means that the >> problem I found should not prevent the other 3 MRAMs from working (U76, 77, >> 78), so it is time to pull out the scope and see what those signals look >> like. >> >> My code is in the same git repository that Chris and Jim have been >> using. Namely https://github.com/AMSAT-NA/PacSatSW.git. I'm not sure >> what you did or how familiar you are with git, but if your IDE is pointing >> to that repository, you will probably have to go to the Team menu and then >> "Fetch from Upstream". This will ensure that you can see locally the >> branches that are upstream (that is in github). Then switch branches to >> WB1FJ_Port_to_Blinky. >> >> I did start with that code (main branch), but a created an entirely new >> HCG project for the TMS570LS0914 (rather than the LS07xxx that was on the >> launchpad. So I can't tell you that I changed exactly x and y from the >> Launchpad version. I just went through all the devices and set them >> correctly, and looked at the code in RTIHU to see which HCG-generated >> modules I had put "user code" in and copied that. I've also removed a lot >> of peripherals that we don't use like CAN. I found that, like you, I had >> to reduce the size of the heap in order to get it to link and load. >> >> I think that my main problem with the serial port was that a) I was not >> 100% sure if 38k4 was the right speed, and b) I connected the Rx and Tx >> lines on my USB-to-serial adapter to the Rx and Tx lines on Blinky. Nope. >> Rx goes to Tx and Tx goes to Rx. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Sun, Feb 4, 2024 at 1:03 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> Burns, >>> >>> I think I have addressed all the issues you raised except pull-ups on >>> SPI. If we don’t need them I can easily remove them from the boards. >>> >>> I will order some 91 nH inductors and a few more values near by and >>> replace the zero ohm resistors. The zero ohm resistors have some inductance >>> by the way. I can measure this with limited accuracy using an inductive >>> bridge I have. I think dynamic testing is needed to prove out best value. >>> May ask Jim to help with that later. >>> >>> I thought you uploaded your code changes to a fork. Can you tell me how >>> to find that? I just looked around and it is not obvious to me. >>> >>> Would you also speak to what you feel got the serial port working? I >>> assume there is a new HCG file in your code I would like to review that. >>> >>> I have another conference call this afternoon with SARA that will go >>> till 3 or so. >>> >>> I would like to test the MRAM on one of the other boards. These chips >>> have not been removed and resoldered. >>> I want to buy four new memory chips and have the assembly house place >>> them on the board you have. >>> May put a loop in the code to test each chip and flash leds with >>> results. Then they could perform a test after soldering. >>> >>> I plane to make all the changes I know about and assemble the boards I >>> have. Hope to get this done and ship all of them out by the end of this >>> week. >>> >>> Will have done limited testing to RF but that can catchup later. >>> >>> Bob >>> >>> On Feb 3, 2024, at 7:42 PM, Bob Stricklin <bstrick(a)n5brg.com> wrote: >>> >>> >>> >>> On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>> I've found a few minor design issues which I don't think will affect us >>> in the short run, but may not be what we want: >>> >>> 1) I already told you (Bob) about the addresses for the Max temp >>> sensors. As set, they collide with two of the possible 4 addresses on an >>> ADS7828, a commonly-used and space-tested A/D converter that some satellite >>> might use. We talked about this before and it should all be straightened >>> out. >>> >>> >>> Yes, Let me add this to the schematic with the new address values to be >>> used on next board build if any. >>> >>> >>> 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to >>> AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the >>> MAX4995SAL power switch/limiter. While you could use these AD1IN pins as >>> an input GPIO (read the voltage and subject it to a threshold for high or >>> low), I don't think it is possible to use these for output. AD1EVT might >>> be usable for output but I'm not sure what effect it would have on the >>> bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. >>> They appear to be usable as GPIO pins and are physically near the ADC pins. >>> >>> >>> Will have to move these lines over as you indicated. Will do that with >>> jumpers. >>> >>> >>> I think the current way it is will work for the moment, since if I read >>> the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. >>> That is, a low value on it turns the power on, and you have a pulldown >>> there. So I think the 5043 and the SSPA will always be on since the ADC >>> inputs should be high impedance. >>> >>> 3) This may just be a doc issue. I think that "PWR_FLAG" on the >>> schematic can't be a circuit, right? OTherwise you'd have lots of weird >>> stuff connected together. If they are actually test points, I think they >>> should be labelled as such (TP1, TP2, etc) and marked in silk screen on the >>> board. >>> >>> >>> This is no problem, an artifact of KiCAD and needed to just to indicate >>> this is a power connection so DRC handles it properly. >>> >>> >>> 4) And finally, from what I have read (and seen on other projects), I >>> don't think the SPI busses need pullup resistors EXCEPT for MISO, and that >>> one should be VERY weak. (One of our devices does not use MISO very often >>> but it appears not to be able to pull much current, thus requiring the >>> really weak pullup. But as I recall a builtin pullup either was not >>> enough, or it could not be used when the pin was used as an SPI device). I >>> can put a scope on the MISO line for the AX5043 to see if it is getting >>> pulled down enough with the 10K. Likewise, I'll see what the other pins >>> look like when connected to the push/pull output of the SPI master. >>> >>> >>> We will add a a pull up resistor for next build. Try to use internal >>> pull up now and if this want cut it we can add a pull-up to these boards. >>> >>> >>> Don't take these critiques as anything other than helpful. I'm no >>> expert here...I just found these things in the process of trying to debug >>> the software, and in a couple cases from tracking down some really PITA >>> problems on Fox and/or Golf! >>> >>> >>> No problem, you are the first person that has looked at things closely >>> and when you start solving issues you are forced to do so. We all make >>> mistakes I have have made plenty. Thanks. >>> >>> >>> 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

One board now talking
by Bob Stricklin 05 Feb '24

05 Feb '24

After getting TX and RX connected correctly now working. Do not know what the correct report back is but here is some checks... This board has four 4Mb MRAMs installed. Pacsat>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat>>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat> Pacsat>get RSSI RSSI is -64 dBm Pacsat> Pacsat>get ax AX5043 dev 1 TX: FIFOSTAT: 00 PWRMODE:: 77 XTALCAP: 119 PLLLOOP: 77 PLLCPI: 77 PLLVCOI: 77 PLLRANGINGA: 77 PLLVCODIV: 77 FREQ 1911466666 Hz MODULATION: 77 TXPWRCOEFFB0: 77 TXPWRCOEFFB1: 77 AX5043 dev 0 RX: FIFOSTAT: 00 PWRMODE: 67 XTALCAP: 103 PLLLOOP: 67 PLLCPI: 67 PLLVCOI: 67 PLLRANGINGA: 67 PLLVCODIV: 67 FREQ 1654462744 Hz MODULATION: 67 TXPWRCOEFFB0: 67 TXPWRCOEFFB1: 67 Pacsat>

1 0

Re: Small bugs to fix (I think)
by Bob Stricklin 05 Feb '24

05 Feb '24

I managed to get the repository into CCS and have tried the Blinky version but still not working for me. I think the board is working but my issue is with the serial interface cable or the terminal program. I backed away from it for a while to work on some other things. Will sort things out later. Also got the Memory version but that one gives me a error message with the programmer and I have not figured out why on this either. Proper programmer is selected. Bob On Feb 5, 2024, at 10:53 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I finally got some wires soldered to the MRAM SPI bus (what a pain! PLEASE put these on some pins for debugging on the next one!) One thing that seems to be happening is that the CLK line is pulled down. I think it should be high. There is a check box for "clock polarity" in HCG, but it is not checked...same as Golf. I'll play more this afternoon. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Sun, Feb 4, 2024 at 1:30 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Hi Bob, I don't have long today, but I with your diagram, I was able to see that there was apparently a via just to the left of U76 for that pin, so I was able to measure continuity to there from the CPU pin 94 (and just to be sure I had the right one I could identify the via just below the processor and measured to that. So what this seems to say is that there is some issue with the trace between U79 pin 2 and U76 pin 2. That means that the problem I found should not prevent the other 3 MRAMs from working (U76, 77, 78), so it is time to pull out the scope and see what those signals look like. My code is in the same git repository that Chris and Jim have been using. Namely https://github.com/AMSAT-NA/PacSatSW.git. I'm not sure what you did or how familiar you are with git, but if your IDE is pointing to that repository, you will probably have to go to the Team menu and then "Fetch from Upstream". This will ensure that you can see locally the branches that are upstream (that is in github). Then switch branches to WB1FJ_Port_to_Blinky. I did start with that code (main branch), but a created an entirely new HCG project for the TMS570LS0914 (rather than the LS07xxx that was on the launchpad. So I can't tell you that I changed exactly x and y from the Launchpad version. I just went through all the devices and set them correctly, and looked at the code in RTIHU to see which HCG-generated modules I had put "user code" in and copied that. I've also removed a lot of peripherals that we don't use like CAN. I found that, like you, I had to reduce the size of the heap in order to get it to link and load. I think that my main problem with the serial port was that a) I was not 100% sure if 38k4 was the right speed, and b) I connected the Rx and Tx lines on my USB-to-serial adapter to the Rx and Tx lines on Blinky. Nope. Rx goes to Tx and Tx goes to Rx. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Sun, Feb 4, 2024 at 1:03 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Burns, I think I have addressed all the issues you raised except pull-ups on SPI. If we don’t need them I can easily remove them from the boards. I will order some 91 nH inductors and a few more values near by and replace the zero ohm resistors. The zero ohm resistors have some inductance by the way. I can measure this with limited accuracy using an inductive bridge I have. I think dynamic testing is needed to prove out best value. May ask Jim to help with that later. I thought you uploaded your code changes to a fork. Can you tell me how to find that? I just looked around and it is not obvious to me. Would you also speak to what you feel got the serial port working? I assume there is a new HCG file in your code I would like to review that. I have another conference call this afternoon with SARA that will go till 3 or so. I would like to test the MRAM on one of the other boards. These chips have not been removed and resoldered. I want to buy four new memory chips and have the assembly house place them on the board you have. May put a loop in the code to test each chip and flash leds with results. Then they could perform a test after soldering. I plane to make all the changes I know about and assemble the boards I have. Hope to get this done and ship all of them out by the end of this week. Will have done limited testing to RF but that can catchup later. Bob On Feb 3, 2024, at 7:42 PM, Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I've found a few minor design issues which I don't think will affect us in the short run, but may not be what we want: 1) I already told you (Bob) about the addresses for the Max temp sensors. As set, they collide with two of the possible 4 addresses on an ADS7828, a commonly-used and space-tested A/D converter that some satellite might use. We talked about this before and it should all be straightened out. Yes, Let me add this to the schematic with the new address values to be used on next board build if any. 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the MAX4995SAL power switch/limiter. While you could use these AD1IN pins as an input GPIO (read the voltage and subject it to a threshold for high or low), I don't think it is possible to use these for output. AD1EVT might be usable for output but I'm not sure what effect it would have on the bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. They appear to be usable as GPIO pins and are physically near the ADC pins. Will have to move these lines over as you indicated. Will do that with jumpers. I think the current way it is will work for the moment, since if I read the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. That is, a low value on it turns the power on, and you have a pulldown there. So I think the 5043 and the SSPA will always be on since the ADC inputs should be high impedance. 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic can't be a circuit, right? OTherwise you'd have lots of weird stuff connected together. If they are actually test points, I think they should be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. This is no problem, an artifact of KiCAD and needed to just to indicate this is a power connection so DRC handles it properly. 4) And finally, from what I have read (and seen on other projects), I don't think the SPI busses need pullup resistors EXCEPT for MISO, and that one should be VERY weak. (One of our devices does not use MISO very often but it appears not to be able to pull much current, thus requiring the really weak pullup. But as I recall a builtin pullup either was not enough, or it could not be used when the pin was used as an SPI device). I can put a scope on the MISO line for the AX5043 to see if it is getting pulled down enough with the 10K. Likewise, I'll see what the other pins look like when connected to the push/pull output of the SPI master. We will add a a pull up resistor for next build. Try to use internal pull up now and if this want cut it we can add a pull-up to these boards. Don't take these critiques as anything other than helpful. I'm no expert here...I just found these things in the process of trying to debug the software, and in a couple cases from tracking down some really PITA problems on Fox and/or Golf! No problem, you are the first person that has looked at things closely and when you start solving issues you are forced to do so. We all make mistakes I have have made plenty. Thanks. 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<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

1 0

Re: Small bugs to fix (I think)
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

Hi Bob, I don't have long today, but I with your diagram, I was able to see that there was apparently a via just to the left of U76 for that pin, so I was able to measure continuity to there from the CPU pin 94 (and just to be sure I had the right one I could identify the via just below the processor and measured to that. So what this seems to say is that there is some issue with the trace between U79 pin 2 and U76 pin 2. That means that the problem I found should not prevent the other 3 MRAMs from working (U76, 77, 78), so it is time to pull out the scope and see what those signals look like. My code is in the same git repository that Chris and Jim have been using. Namely https://github.com/AMSAT-NA/PacSatSW.git. I'm not sure what you did or how familiar you are with git, but if your IDE is pointing to that repository, you will probably have to go to the Team menu and then "Fetch from Upstream". This will ensure that you can see locally the branches that are upstream (that is in github). Then switch branches to WB1FJ_Port_to_Blinky. I did start with that code (main branch), but a created an entirely new HCG project for the TMS570LS0914 (rather than the LS07xxx that was on the launchpad. So I can't tell you that I changed exactly x and y from the Launchpad version. I just went through all the devices and set them correctly, and looked at the code in RTIHU to see which HCG-generated modules I had put "user code" in and copied that. I've also removed a lot of peripherals that we don't use like CAN. I found that, like you, I had to reduce the size of the heap in order to get it to link and load. I think that my main problem with the serial port was that a) I was not 100% sure if 38k4 was the right speed, and b) I connected the Rx and Tx lines on my USB-to-serial adapter to the Rx and Tx lines on Blinky. Nope. Rx goes to Tx and Tx goes to Rx. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sun, Feb 4, 2024 at 1:03 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > I think I have addressed all the issues you raised except pull-ups on SPI. > If we don’t need them I can easily remove them from the boards. > > I will order some 91 nH inductors and a few more values near by and > replace the zero ohm resistors. The zero ohm resistors have some inductance > by the way. I can measure this with limited accuracy using an inductive > bridge I have. I think dynamic testing is needed to prove out best value. > May ask Jim to help with that later. > > I thought you uploaded your code changes to a fork. Can you tell me how to > find that? I just looked around and it is not obvious to me. > > Would you also speak to what you feel got the serial port working? I > assume there is a new HCG file in your code I would like to review that. > > I have another conference call this afternoon with SARA that will go till > 3 or so. > > I would like to test the MRAM on one of the other boards. These chips have > not been removed and resoldered. > I want to buy four new memory chips and have the assembly house place them > on the board you have. > May put a loop in the code to test each chip and flash leds with results. > Then they could perform a test after soldering. > > I plane to make all the changes I know about and assemble the boards I > have. Hope to get this done and ship all of them out by the end of this > week. > > Will have done limited testing to RF but that can catchup later. > > Bob > > On Feb 3, 2024, at 7:42 PM, Bob Stricklin <bstrick(a)n5brg.com> wrote: > > > > On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I've found a few minor design issues which I don't think will affect us in > the short run, but may not be what we want: > > 1) I already told you (Bob) about the addresses for the Max temp sensors. > As set, they collide with two of the possible 4 addresses on an ADS7828, a > commonly-used and space-tested A/D converter that some satellite might > use. We talked about this before and it should all be straightened out. > > > Yes, Let me add this to the schematic with the new address values to be > used on next board build if any. > > > 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to > AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the > MAX4995SAL power switch/limiter. While you could use these AD1IN pins as > an input GPIO (read the voltage and subject it to a threshold for high or > low), I don't think it is possible to use these for output. AD1EVT might > be usable for output but I'm not sure what effect it would have on the > bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. > They appear to be usable as GPIO pins and are physically near the ADC pins. > > > Will have to move these lines over as you indicated. Will do that with > jumpers. > > > I think the current way it is will work for the moment, since if I read > the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. > That is, a low value on it turns the power on, and you have a pulldown > there. So I think the 5043 and the SSPA will always be on since the ADC > inputs should be high impedance. > > 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic > can't be a circuit, right? OTherwise you'd have lots of weird stuff > connected together. If they are actually test points, I think they should > be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. > > > This is no problem, an artifact of KiCAD and needed to just to indicate > this is a power connection so DRC handles it properly. > > > 4) And finally, from what I have read (and seen on other projects), I > don't think the SPI busses need pullup resistors EXCEPT for MISO, and that > one should be VERY weak. (One of our devices does not use MISO very often > but it appears not to be able to pull much current, thus requiring the > really weak pullup. But as I recall a builtin pullup either was not > enough, or it could not be used when the pin was used as an SPI device). I > can put a scope on the MISO line for the AX5043 to see if it is getting > pulled down enough with the 10K. Likewise, I'll see what the other pins > look like when connected to the push/pull output of the SPI master. > > > We will add a a pull up resistor for next build. Try to use internal pull > up now and if this want cut it we can add a pull-up to these boards. > > > Don't take these critiques as anything other than helpful. I'm no expert > here...I just found these things in the process of trying to debug the > software, and in a couple cases from tracking down some really PITA > problems on Fox and/or Golf! > > > No problem, you are the first person that has looked at things closely and > when you start solving issues you are forced to do so. We all make mistakes > I have have made plenty. Thanks. > > > 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