Re: AX5043 SPI working on Blinky
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
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
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
participants (2)
-
Burns Fisher (AMSAT) -
Chris Thompson