Jonathan, did I send you the extra Launchpad that I ended up with? In any case, do you want to give one to Corey? Corey, you may have to solder on some .1" header pins for Jim's board to have all the required connections. I know the headers are DNP around the outside where they are not used, but I'm not sure that all the inside ones are there either.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Apr 7, 2023 at 12:30 PM Corey Minyard via pacsat-dev < pacsat-dev@amsat.org> wrote:
Corey et al,
I pulled down the filesystem branch and have gotten it running on my LaunchPad with 2 512K MRAMs.
First, thanks for cleaning up the MRAM code. As you might have guessed, the read/write was originally to choose between the MRAM and Flash memory on the STM32L processor. On the RTIHU, I just cut out the stuff for the flash. Looks like you have used the same basic scheme between the two partitions in the MRAM. I like it!
I have had to make two (identical) changes to get it to compile, and one more to get it to run:
1) I'm not entirely sure why the "reliance-edge" and its "core" subfolder were setup with different properties than everything else (that's the little key badge means, I think, although I've never been able to get rid of it once it was there!). But in any case, the changed setup had a path that was specific to your machine so it could not find <string.h>. I changed it to ${CG_TOOL_ROOT) in both places. Now it compiles.
2) Formatting the file system failed with a not-very-useful error message (Invalid Argument). The problem is that REDCONF_ENDIAN_BIG needs to be defined to 1 in redconf.h.
So now it formats and mounts ok. I have not tried anything else.
I'll push what I have right now up on my own branch named "BFFileSystem". Then I want to see why there are some MRAM errors when it first boots. Probably some old code.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Apr 7, 2023 at 12:40 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
On Fri, Apr 07, 2023 at 04:31:23PM -0400, Burns Fisher (AMSAT) wrote:
Yeah, Chris had the same issue. I've never used this IDE, and I don't like IDEs in general. I added those properties because I wanted specific include for the things inside reliance-edge (lots of internal includes) that I didn't want outside things using.
Chris noticed that, too. I assumed that since this was ARM it was little endian.
I've fixed all these things in my branch and just added some error reporting to try to track down why this was happening.
I gave 1024 bytes for the partition 0, which seemed like enough from my calculations. Maybe it wasn't?
-corey
I assumed that since this was ARM it was little endian.
Yeah, I would have too. But apparently ARM can go either way. Turns out that for some reason the automotive world seems to standardize on big endian. This has caused nothing but hassle on the TMS570 (the STM32L is little).
participants (2)
-
Burns Fisher (AMSAT) -
Corey Minyard