But the mram wren does not work as expected.  First this:
Pacsat>get mram sr
MRAM status is ef

This is a bit surprising.  Indeed, some of the non-functional bits are different on the FRAM and the MRAM.  On the MRAM, bits 6,5,4 and 0 have no effect but can be written and read.  I'm not sure if they are volatile, but on the MRAM, they are said to be factory set to 0.  On the FRAM, bit 6 is defined to be 1.  Bits 5,4,0 are all 0.  So that explains some of it.  However, on both bits 3 and 2 are write protects for various banks, so I'm not 100% sure why they would be set.  Bit 7 I would expect to be 0 (which means ignore the external write protect pin) and bit 1 I would expect to be 1, which is the write enable latch turned on by the wren command.


 

Hmm, so I did these two commands:
Pacsat>mram wren
stat for Wren is 1; sr is 2

Pacsat>>get mram sr
MRAM status is 2

These are exactly correct given that bit 6 is not forced to 1 as it was on the FRAM.


 
73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software


On Fri, Dec 2, 2022 at 4:37 PM Chris Thompson <chrisethompson@gmail.com> wrote:
I will test this again soon.  Might be tomorrow morning though.

73
Chris 

On Fri, Dec 2, 2022, 16:34 Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
Ok, I moved everything to printID and removed duplicate data.

BTW, at some point, I'll put in code to actually figure out the MRAM sizes (and probably put them in a particular MRAM location so we don't have to keep doing it!)  Right now, I think it is hard-coded.

73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software


On Fri, Dec 2, 2022 at 3:44 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
Ok, I see what was happening.  I missed setting the chip select to function as a GPIO (which is how the driver uses it).  Let me look at your other comments, and I'll fix it and check it in.
73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software


On Fri, Dec 2, 2022 at 3:14 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
I did not change it, but it is possible that I did not set it up correctly in HALCoGen.  I'll check in a few.

73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software


On Fri, Dec 2, 2022 at 2:52 PM Chris Thompson <chrisethompson@gmail.com> wrote:
Did you also change the SPI bus for the radio?  It does not initialize in your branch.  If you did not change it then I will see if I did something wrong.  I just merged your changes into mine.

73
Chris

On Fri, Dec 2, 2022 at 2:48 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
The SR may be different on the MRAM from my FRAM.  I'll check and get back to you.  The "2" bit is certainly correct..
73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software


On Fri, Dec 2, 2022 at 2:38 PM Chris Thompson <chrisethompson@gmail.com> wrote:
Ok great.  That seems to work.  Here is the mram command output:
Pacsat>>test mram 80
Starting at address 80:
 Data 1 should be 1 1 1 1 8 10 12 14
First read/write cycle for data 1 is 1 1 1 1 8 10 12 14
Second read/write cycle for data 1 is 1 1 1 1 8 10 12 14
Starting at address 80:
 Data 2 should be 2 2 2 2 3 2 1 30
Read back for data 2 is 2 2 2 2 3 2 1 30

But the mram wren does not work as expected.  First this:
Pacsat>get mram sr
MRAM status is ef

Hmm, so I did these two commands:
Pacsat>mram wren
stat for Wren is 1; sr is 2

Pacsat>>get mram sr
MRAM status is 2

Is that what you expect?

73
Chris






On Fri, Dec 2, 2022 at 2:22 PM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
Oops!  I totally forgot!  On J11, 32 is ground, 33, 34 for Rx and Tx (I just reversed them till it worked).  It is still 38k4 baud.
73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software


On Fri, Dec 2, 2022 at 2:17 PM Chris Thompson <chrisethompson@gmail.com> wrote:
Hi Burns,

This compiles and flashes fine here, but I think I need to know the new UART pins.  I think you moved them from the HET, right? 

73
Chris

On Fri, Dec 2, 2022 at 10:53 AM Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:
Hi,

As discussed last night, I have a HALCoGen configuration set up that is specifically designed for the LaunchPad.   I've also added a command "test mram" and another called "mram wren".  The former writes 10 bytes into the mram at a specified address and then reads them back.  It prints what it was writing, and what the read-back results are.  It does this twice with one pattern of data and once with a different one.   You can specify an address following the command.  For example "test mram 100".  It will take 0xnnn" as well for hex

"mram wren" sends a write enable command to the mram.   The existing command "get mram sr" should show this.  If it returns "40" the chip is not write enabled.  If it returns 42, it is write enabled.

There is also, in config.h, a #ifdef FRAM64K.  If this is set, the address sent to the non-volatile RAM is 2 bytes.  If it is not defined (just comment it out) it will be 3 bytes.  I've left it set up for 3-byte addresses since that is what Chris is using.

Please let me know if you have tried this successfully, especially with a real MRAM (most of those tests were for my funky F-RAM).  If so, I'll move it to the main branch.

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


--


--


--