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