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

Re: One more time to try--I think I am done :-)
by Chris Thompson 11 Feb '24

11 Feb '24

All sounds good Burns. I'm looking forward to testing this. As I told the others last Thursday, it will be after my ARISS conference, which is the week of Feb 19th. Bob will send the board to me in Florida and I will hand carry it back (hopefully convincing customs that duties should be waived, or paying the bill in person!). No problem on delaying the merge. We can work off a branch for now and I can merge it later. It's good practice I think for main to be a version that is tested and works. 73 Chris On Sun, Feb 11, 2024, 17:21 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Version X0.2a pushed upstrem. This is all still in the branch > WB1FJ_Port_to_Blinky > > First you will note that it will frequently tell you that you have the > wrong MRAM version. Some of these warnings were commented out. I may have > done it in debugging, but it is important. Lots of things may not work > right if this message appears. It gives several alternatives of commands > that you can issue, but in this particular case, > > YOU MUST ISSUE THE COMMAND 'init new proc'. > > After that the messages will stop. The reason for all this is that I > added 3 more receive frequency locations in MRAM, and those are only set up > with init new proc. > > This new version, as I implied above, saves 4 different receive > frequencies. "init new proc' initializes them all the same, but you can > adjust them with "raise rx freq n m" where n is the receiver number (1-4) > and n is the number (in Hz) to raise the frequency by. There is also > 'lower rx freq'. The versions for tx freq do not have a chip number. The > maximum you can change the frequency for any of these (I think) is 32767Hz > (it is 15 bits). > > BTW, I think this is actually transmitting something. If I have the tx > frequency set out of range, I get a TX queue filling up. ?????? > > Anyway, let me know if you have questions or if you need other stuff. I'm > done for now. And btw, we are again expecting snow Tuesday, so my band > rehearsal may be moved to Thursday again :-( > > 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

One more time to try--I think I am done :-)
by Burns Fisher (AMSAT) 11 Feb '24

11 Feb '24

Version X0.2a pushed upstrem. This is all still in the branch WB1FJ_Port_to_Blinky First you will note that it will frequently tell you that you have the wrong MRAM version. Some of these warnings were commented out. I may have done it in debugging, but it is important. Lots of things may not work right if this message appears. It gives several alternatives of commands that you can issue, but in this particular case, YOU MUST ISSUE THE COMMAND 'init new proc'. After that the messages will stop. The reason for all this is that I added 3 more receive frequency locations in MRAM, and those are only set up with init new proc. This new version, as I implied above, saves 4 different receive frequencies. "init new proc' initializes them all the same, but you can adjust them with "raise rx freq n m" where n is the receiver number (1-4) and n is the number (in Hz) to raise the frequency by. There is also 'lower rx freq'. The versions for tx freq do not have a chip number. The maximum you can change the frequency for any of these (I think) is 32767Hz (it is 15 bits). BTW, I think this is actually transmitting something. If I have the tx frequency set out of range, I get a TX queue filling up. ?????? Anyway, let me know if you have questions or if you need other stuff. I'm done for now. And btw, we are again expecting snow Tuesday, so my band rehearsal may be moved to Thursday again :-( 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: Lots of things working--I'm pretty much done for now
by Chris Thompson 10 Feb '24

10 Feb '24

Great progress Burns. All sounds good. The RX uses the interrupt, so that will need to be setup for all 4. To test it you need to send it a packet I suppose... The TX should have an interrupt configured but we don't use it so far. But we need it to support packets longer than 255 bytes. That is important if we want to add FEC bytes. On the branches we should create a launchpad one from main before we merge blinky into main. And or add a release Tag for launchpad. Then, as long as we don't change the HCG stuff in the launchpad branch (or other incompatible things), we should probably be able to merge changes from launchpad branch back into blinky. If that is ever required. 73 Chris On Fri, Feb 9, 2024, 17:31 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I > think that this has essentially everything that I planned to do (although > see the end). > > 1) I2c temp sensors working > 2) SPI access to AX5043 working. (Oh, I have not tested interrupts. I > don't know with the current setup how to make one. Tell me if it does not > work and how to do something that SHOULD cause it to interrupt, and I will > fix it.) > 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my > board and it does not have 3, but they all work on Bob's so I assume that > is all ok. > 4) All tasks are started. What they do is not my baliwick! > 5) MRAM init routines are working. Depending on what you do, these will > figure out how many address bytes are required (always 3 for blinky, always > 2 for Launchpad, so that could be hard-coded). They will also figure out > the MRAM size as well as the number of MRAM chips, and set up the chips so > that the partitions do what they should. (II can't test odd configurations > but 1 MRAM works and 4 works.) > > New info: When starting on a brand new processor (and I'd recommend it on > the current ones that we have been using), I don't think it will crash > unless none of the MRAMs work. But the first thing you should do is to > issue the command "init new proc". This will init a lot of MRAM stuff, > including the default AX5043 frequencies for two of the 5043s (one Rx and > one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq > nnn" to raise and lower them. Save them with "save freq". Rebooting or > "preflight init" will not change them. > > If you do "get mram sr" to look at the status registers, that is an easy > way to tell which MRAMs are present. The status register for those not > present will read 0xff. The first one present will read 0x32. Others will > just read 2. "get mram size" will also give useful info. > > Pacsat>get mram sr > MRAM0: status ff, MRAM1: status 32 > MRAM2: status ff, MRAM3: status ff > 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 > > What I have left to do: > > Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. > Make a place to store them in MRAM, set default values, etc. > > Check for even more stuff that can be removed. I think there are a number > of unused commands which may have no code, but will still show up in help, > for example. > > Debug 5043 interrupts if there is a problem. Actually is it the case that > only Tx uses interrupts and not Rx? If Rx, there is more to do to make all > 4 of them work. > > In the meantime, though, Chris and Jim, I think you can play with this as > soon as you get a blink. One thing to note: Be sure to keep blinky and > launchpad on separate branches. Especially the HalCoGen stuff is much > different but also anything that knows how many MRAMs and how many 5043s > there are. Those won't merge easily if at all. > > I'll try to do at least the rx freq stuff tomorrow. I totally forgot > about that until a few minutes ago. > > 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

Lots of things working--I'm pretty much done for now
by Burns Fisher (AMSAT) 09 Feb '24

09 Feb '24

I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I think that this has essentially everything that I planned to do (although see the end). 1) I2c temp sensors working 2) SPI access to AX5043 working. (Oh, I have not tested interrupts. I don't know with the current setup how to make one. Tell me if it does not work and how to do something that SHOULD cause it to interrupt, and I will fix it.) 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my board and it does not have 3, but they all work on Bob's so I assume that is all ok. 4) All tasks are started. What they do is not my baliwick! 5) MRAM init routines are working. Depending on what you do, these will figure out how many address bytes are required (always 3 for blinky, always 2 for Launchpad, so that could be hard-coded). They will also figure out the MRAM size as well as the number of MRAM chips, and set up the chips so that the partitions do what they should. (II can't test odd configurations but 1 MRAM works and 4 works.) New info: When starting on a brand new processor (and I'd recommend it on the current ones that we have been using), I don't think it will crash unless none of the MRAMs work. But the first thing you should do is to issue the command "init new proc". This will init a lot of MRAM stuff, including the default AX5043 frequencies for two of the 5043s (one Rx and one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq nnn" to raise and lower them. Save them with "save freq". Rebooting or "preflight init" will not change them. If you do "get mram sr" to look at the status registers, that is an easy way to tell which MRAMs are present. The status register for those not present will read 0xff. The first one present will read 0x32. Others will just read 2. "get mram size" will also give useful info. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff 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 What I have left to do: Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. Make a place to store them in MRAM, set default values, etc. Check for even more stuff that can be removed. I think there are a number of unused commands which may have no code, but will still show up in help, for example. Debug 5043 interrupts if there is a problem. Actually is it the case that only Tx uses interrupts and not Rx? If Rx, there is more to do to make all 4 of them work. In the meantime, though, Chris and Jim, I think you can play with this as soon as you get a blink. One thing to note: Be sure to keep blinky and launchpad on separate branches. Especially the HalCoGen stuff is much different but also anything that knows how many MRAMs and how many 5043s there are. Those won't merge easily if at all. I'll try to do at least the rx freq stuff tomorrow. I totally forgot about that until a few minutes ago. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: AX Frequencies
by Burns Fisher (AMSAT) 09 Feb '24

09 Feb '24

Great! One last thing I will do is turn on the other tasks and make sure it does not crash now that the mrams are working. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 10:57 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > All the AX frequencies are being set properly. RX frequency 145835000Hz, > TX 435759999Hz. So we are writing and reading the AX devices. > > Bob > > > ----------------------------------------------------------- > > 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

AX Frequencies
by Bob Stricklin 09 Feb '24

09 Feb '24

All the AX frequencies are being set properly. RX frequency 145835000Hz, TX 435759999Hz. So we are writing and reading the AX devices. Bob

1 0

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

08 Feb '24

Get MRAM size reports 512 which is 512 x 8 so 4 meg. Test MRAM seems to be working. On Feb 8, 2024, at 4:47 PM, Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org> wrote: <IMG_0005.jpeg> Ok, I did clean project. Rebuild and load. The clear MRAM See 4 now. Bob On Feb 8, 2024, at 4:40 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: <IMG_0004.jpeg> I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> 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<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 ----------------------------------------------------------- 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 ----------------------------------------------------------- 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

[IMG_0005] Ok, I did clean project. Rebuild and load. The clear MRAM See 4 now. Bob On Feb 8, 2024, at 4:40 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: <IMG_0004.jpeg> I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> 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<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 ----------------------------------------------------------- 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 ----------------------------------------------------------- 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

It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > [image: IMG_0004] > > > I see version is q so I think this is most current. Not seeing 4 chips > yet. > > Bob > > On Feb 8, 2024, at 4:01 PM, Burns > > > Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > > Ok, please also get X0.1q (just pushed upstream). > > I may have said before that I got one MRAM to work on my board. Now I > have changed a few things so that it seems to do at least some of the tests > correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if > it will work with yours as well. But anyway, it is an improvement. Do > "clear mram" first. > > > Pacsat>get mram sr > MRAM0: status ff, MRAM1: status 32 > MRAM2: status ff, MRAM3: status ff > > Pacsat>clear mram > Post Launch Time Set to 2 minutesSet to start in safe mode > WOD Frequency,size set to Default, and WOD Indices initialized > Telemetry min/max in MRAM initialized > Reset Count set to 0 > Nonfatal error count zeroed (TBD) > CRC calculated for init code and full code (TBD) > MRAM Version Number Initialized > MRAM config partition size is 1008 bytes > MRAM file partition 1 size is 523280 > > Pacsat>get mram size > MRAM Address Size=3 > Partition 0 size=1008, partition 1=523280 > MRAM0 size is 0KBytes, MRAM1 size is 512KBytes > MRAM2 size is 0KBytes, MRAM3 size is 0KBytes > Pacsat>test mram 4 42 > NOTE: This test will wipe out the file system and configuration values in > MRAM. > > Testing with read/write size = 4 bytes, random value base is 0x1864 > Write starting at 0KB > Write starting at 16KB > Write starting at 32KB > Write starting at 48KB > Write starting at 64KB > Write starting at 80KB > <skipping a bunch of additional writes> > Read starting at 0KB > Read starting at 16KB > Read starting at 32KB > Read starting at 48KB > Read starting at 64KB > Read starting at 80KB > Read starting at 96KB > Read starting at 112KB > Read starting at 128KB > <...> > Read starting at 432KB > Read starting at 448KB > Read starting at 464KB > Read starting at 480KB > Read starting at 496KB > Read starting at 512KB > Test is ok! Time is 37 seconds > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Ok Burns. Will check soon. At the gym and will be home in about 30 >> minutes. >> >> Good that you fixed this. >> >> I added 20k pull-up on MOSI and security chip. Also moved the enable >> lines on the two supply control chips will give details on that later. >> >> Bob >> >> On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> >> I got one MRAM working, specifically #1. I apparently fixed the chip >> select for that one. >> >> Please try "get mram sr" with X0.1p. If they say something other than >> 0xff, they are probably working. Don't mess with the other MRAM commands >> unless it sees all the MRAMs. I think a lot of that code assumes there are >> 4 good MRAMs. >> >> In the meantime, I now KNOW that most the SPI bus is ~good on my board, >> so I'll focus a bit more on the chip selects for 0 and 2. If I have time, >> I'll see if I can get some of the other tests working for only some MRAMs. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> Ok, Bob, glad you figured out how to get the new code. >>> >>> Regarding the MRAM. I at first thought that you said "okay", but now I >>> think you said zero K. I originally set up the MRAM code to figure out >>> the size of the MRAMs, whether they needed 2 or 3 address bytes, and how >>> many were present. But I only had the one example of Jim's launchpad >>> board, so I'm not surprised it is not quite right for larger MRAMs and >>> especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and >>> 3 do not). But since none work on my board, I could not do anything more. >>> As soon as I can get a board with working MRAMs, I'll fix all that. Also >>> with all the MRAM errors that I get I have disabled a number of the tasks >>> because they quickly failed and reset the processor. I'll fix that when I >>> get a working MRAM board. >>> >>> Regarding the 5043: Did you do "test ax"? That shows a couple >>> registers from each of the 5043s which we know the value of. I think you >>> can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did >>> not display all 5 just because I did not know the correct values anyway, >>> and it would just run off the bottom of the screen :-) >>> >>> More in a separate mailing. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> I resolved the issue with GIT I had. >>>> >>>> I was setting things up initially with my GIT username and password and >>>> apparently you must in CCS. >>>> >>>> I have built and run Version ‘o’. >>>> >>>> I am seeing data back from 2 of the AX5043s. Probably need to expand >>>> code to work with all 4 devices. Later. >>>> >>>> get ax returns this …. screen capture >>>> >>>> <Screenshot from 2024-02-08 02-56-00.png> >>>> >>>> get mram size just returns two of the mram 0 and 2 and indicates >>>> their size is 0k. >>>> test mram 1 42 seems to run saying Write starting at etc and goes from >>>> 0KB to 1024KB. Then it does a Read in same area and does not report any >>>> errors but says: Test is OK! Time is 75 seconds. >>>> MRAM chips are 4 meg so maybe code only setup for 1 meg. >>>> >>>> >>>> More testing on hardware later today. >>>> >>>> Bob >>>> >>>> >>>> On Feb 7, 2024, at 10:47 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>>> wrote: >>>> >>>> Yes, the same branch. What errors are you getting? >>>> 73, >>>> >>>> Burns Fisher, WB1FJ >>>> *AMSAT(R) Engineering -- Flight Software* >>>> >>>> >>>> On Wed, Feb 7, 2024 at 11:33 AM Bob Stricklin <bstrick(a)n5brg.com> >>>> wrote: >>>> >>>>> Burns, >>>>> >>>>> Confirm for me the branch you are working with is >>>>> WB1FJ_Port_to_Blinky >>>>> >>>>> I am having an issue getting a clean build. I know you were still >>>>> working CS problem but I am trying to get the GIT build process to work >>>>> properly. >>>>> >>>>> Bob >>>>> >>>>> On Feb 6, 2024, at 5:34 PM, Bob Stricklin <bstrick(a)n5brg.com> wrote: >>>>> >>>>> OK >>>>> >>>>> Bob >>>>> >>>>> On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev < >>>>> pacsat-dev(a)amsat.org> wrote: >>>>> >>>>> I'm reasonably sure that I have the chip select lines screwed up in >>>>> s/w. I have band rehearsal tonight, so I won't be able to do anything >>>>> till tomorrow. >>>>> >>>>> 73, >>>>> >>>>> Burns Fisher, WB1FJ >>>>> *AMSAT(R) Engineering -- Flight Software* >>>>> >>>>> >>>>> On Tue, Feb 6, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>>>> wrote: >>>>> >>>>>> I added a quick test to tell if the 5043 SPI interface is working. >>>>>> This is in version 0.1n and has been pushed upstream. >>>>>> >>>>>> Pacsat>test ax >>>>>> AX5043 #0: Revision=7, scratch=7 >>>>>> AX5043 #1: Revision=7, scratch=7 >>>>>> AX5043 #2: Revision=119, scratch=119 >>>>>> AX5043 #3: Revision=7, scratch=7 >>>>>> AX5043 #4: Revision=119, scratch=119 >>>>>> AX5043 #5: Revision=7, scratch=7 >>>>>> >>>>>> This is what it looks like. However the numbers are all wrong. I'm >>>>>> not sure how they can be other than right or 0xff, but something is screwed >>>>>> up. The Revision should be 0x51, which would be printed in decimal as 81. >>>>>> The scratch register, I wrote the AX5043 number into, so each one should >>>>>> read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. >>>>>> >>>>>> You might as well try it on yours Bob. In the meantime, I'll try to >>>>>> see if I can tell anything on mine. >>>>>> >>>>>> 73, >>>>>> >>>>>> Burns Fisher, WB1FJ >>>>>> *AMSAT(R) Engineering -- Flight Software* >>>>>> >>>>> >>>>> ----------------------------------------------------------- >>>>> >>>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>>> View archives of this mailing list at >>>>> https://mailman.amsat.org/hyperkitty/list/[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 > > > ----------------------------------------------------------- > > 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

[IMG_0004] I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> 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<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 ----------------------------------------------------------- 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