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