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*
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
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
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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 >
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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 >> > > > -- > Chris E. Thompson > chrisethompson@gmail.com > g0kla@arrl.net >
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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 >>> >> >> >> -- >> Chris E. Thompson >> chrisethompson@gmail.com >> g0kla@arrl.net >> >
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
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 >>>> >>> >>> >>> -- >>> Chris E. Thompson >>> chrisethompson@gmail.com >>> g0kla@arrl.net >>> >> > > -- > Chris E. Thompson > chrisethompson@gmail.com > g0kla@arrl.net >
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
participants (2)
-
Burns Fisher (AMSAT) -
Chris Thompson