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@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@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@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@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@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@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

---

pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

---

pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org