I will test this with my MRAM, but I am taking a break at the moment due to a relapse with my arm pain. Unfortunately I have not made further progress with the AX5043 chip either. Hopefully soon.73ChrisOn Sun, Dec 11, 2022 at 5:23 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:Also, the multi-MRAM support is now merged into the main branch. I just realized that I should have asked Chris to test it with a single MRAM. My apologies, but I did want to get this code out to share. When there are many more people working on code, we must work out our branch expectations.73,Burns Fisher, WB1FJAMSAT(R) Engineering -- Flight Software-----------------------------------------------On Sun, Dec 11, 2022 at 5:07 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:I've been checking the "sleep" power situation. I put an ammeter in series with ground going to the breadboard which holds only the MRAM. Thus, it should include not only MRAM Vss/Vdd current but also current used via the bus lines. The supply voltage is about 3.25V (the output from the 3.3V line on the Launchpad. Here is what we see with two MR25H40 devices with the clock at 2MHz.Quiescent Awake: 160 uAWriting 9.1-9.3mA (This includes sending a WREN (write enable) command for each write command)Reading 6.6-6.4mAMRAM0 asleep, MRAM1 quiescent: 81uABoth Asleep: 2uASummary:Reading and writing takes on the order of 50 times as much power as quiescent (you can do the math with more precision)Quiescent takes relatively little powerSleep cuts the quiescent power for each MRAM from about 81uA to about 1uA.So my current thoughts about using sleep:PRO:--Sure it cuts the power use by 98% when the MRAM is not in use.CON:--But the savings is 98% of a "small" amount: 160uA.--The savings is only when the MRAM is not in use. (If one is in use and one sleeping, the power reduction is trivial)--The spec says we must explicitly send a wake command and wait 400uS before we can use an MRAM that is currently asleep. This is a significant time without some additional software.--The software is a bit less simple than I had hoped; we would have to use a timer and only sleep after a TBD time had passed with no memory ops. If we sleep at each op, the MRAM is hundreds of times slower.I make no recommendation because the group may decide that the larger number of "CONs" are not as important as the PRO.I'll check higher clock speeds at some point, but remember that all the power savings above is from quiescent (no clock) to sleep, so I would not expect a difference only in the read/write power.73,Burns Fisher, WB1FJAMSAT(R) Engineering -- Flight SoftwareOn Sun, Dec 11, 2022 at 1:04 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:I think one of us found a nice small file system. Sorry, I don't remember which one of you did that! Do you think it is testable with 1MB storage?I also have the code set up so it should be relatively easy to add more MRAMs if we want more space. And one of my next projects will be to measure the power used, and also to see if I can make them sleep when not in use. I'm thinking that we could also use a few dozen bytes for changeable but more-or-less permanent data and then use the rest of the MRAMs for the file system. The fixed location stuff would just be stuff like the radio frequencies, command encryption key, reset count, a few odds and ends of parameters that we might want to be able to command.73,Burns Fisher, WB1FJAMSAT(R) Engineering -- Flight SoftwareOn Sun, Dec 11, 2022 at 8:50 AM Chris Thompson <chrisethompson@gmail.com> wrote:Well done Burns!Have we decided what the best method will be to read and write a file to the MRAM? To simplify things we could assume files do not change size after writing, except the telemetry where we can preallocate the required size. For other files we must always receive the header first, which holds the file size.73ChrisOn Sat, Dec 10, 2022, 17:50 Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:-----------------------------------------------Below is the console output from the current software. "test mram" writes the address into every 4-byte MRAM cell from 0 to 1MB and then reads it back to check. Believe me, I've had plenty of cases where it does not match and it printed it out. (It was essentially always my error!)Pacsat>get mram size
Size of MRAM0 is 512KB
Size of MRAM1 is 512KB
Pacsat>
Pacsat>
Pacsat>
Pacsat>test mram
0KB written
64KB written
128KB written
192KB written
256KB written
320KB written
384KB written
448KB written
512KB written
576KB written
640KB written
704KB written
768KB written
832KB written
896KB written
960KB written
0KB read
64KB read
128KB read
192KB read
256KB read
320KB read
384KB read
448KB read
512KB read
576KB read
640KB read
704KB read
768KB read
832KB read
896KB read
960KB read73,Burns Fisher, WB1FJAMSAT(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
--