<M9names[m]>
from the board user manual (FPB-R9A02G021 User's Manual, section 5.2):
<thejpster[m]>
I will check them, but given I was able to program it once, I’ll be amazed if it’s not set to onboard JTAG.
<thejpster[m]>
Maybe the UART boot loader still works though. I could try that.
<thejpster[m]>
So ... J5 and J6 are bare through-holes with no jumpers installed.
<thejpster[m]>
Ah, they are for the UART. Maybe I'll fit them so I can talk to the UART using the J-Link OB.
AlexandervanSaas has joined #rust-embedded
<AlexandervanSaas>
I'm playing around with the idea of writing a file system for NOR flash chip. In the embedded_storage_async::nor_flash::NorFlash docs for the write method it says "It is not allowed to write to the same word twice." Is that a note for implementers or for callers? My plan is to encode block states with bitflags, making use that writes can only flip 1's to 0's, but that requires writing to the same byte multiple times
<AlexandervanSaas>
* I'm playing around with the idea of writing a file system for NOR flash chip. In the embedded_storage_async::nor_flash::NorFlash docs for the write method it says "It is not allowed to write to the same word twice." Is that a note for implementers or for callers? My plan is to encode block states with bitflags, making use of the property that writes can only flip 1's to 0's. This requires writing to the same byte
<AlexandervanSaas>
multiple times without erasing so I want to make sure that's okay.
<AlexandervanSaas>
* I'm playing around with the idea of writing a file system for NOR flash chips. In the embedded_storage_async::nor_flash::NorFlash docs for the write method it says "It is not allowed to write to the same word twice." Is that a note for implementers or for callers? My plan is to encode block states with bitflags, making use of the property that writes can only flip 1's to 0's. This requires writing to the same byte
<AlexandervanSaas>
multiple times without erasing so I want to make sure that's okay.
pronvis has joined #rust-embedded
<diondokter[m]>
<AlexandervanSaas> "I'm playing around with the idea..." <- That's for callers. You may indeed only call it once
<AlexandervanSaas>
Okay then I'll need to figure something else out.
<AlexandervanSaas>
The word size here is given by the `WRITE_SIZE` constant, right? I see in `sequential-storage` you create a new const for the word size that's the maximum of the read and write size.
<AlexandervanSaas>
Also, does writing `OxFF` "count"?
<diondokter[m]>
<AlexandervanSaas> "Also, does writing `OxFF` "count..." <- Yes, only once is allowed
<diondokter[m]>
<AlexandervanSaas> "The word size here is given by..." <- Yes, that's for ease of implementation. Dealing with 2 word sizes is awful
<AlexandervanSaas>
Alright, thanks. Back to the drawing board for me.
<AlexandervanSaas>
Btw, the problem I'm trying to solve is minimizing the storage overhead of doing many small writes to an open file. I think COBS encoding with a `0xFF` delimiter would make it easy to know where the end of the file is and if there's space for more bytes. Maybe it's a stupid idea but it seems like an interesting experiment.
<diondokter[m]>
<AlexandervanSaas> "Btw, the problem I'm trying to..." <- You'll still need to do page handling. And you'll need to be able to fully recover the state when you reboot. Also, what about data protection? If you want to support external flash chips, or any flash chip without ecc, you may want error correction codes or at least some CRC's
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bitts[m]>
openocd doesn't allow reading memory while the target is running for aarch64, is there a good reason for this? I was trying to get rtt to work...
<AlexandervanSaas>
<diondokter[m]> "You'll still need to do page..." <- Yep. That's why I wanted to encode the block state using bitflags so I can get the page state by only reading a few bytes. For data protection I think I'll do a CRC at the block level. Or maybe all this can be put in the inode. Idk, still lots to think about!
<FrreJacques[m]>
I thought I may have set the pins to low to not read the high I set myself. But doing that I only read lows.
turbofish has quit [Ping timeout: 248 seconds]
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
<FrreJacques[m]>
Nevermind. I think it should work. I guess I have a bug elsewhere that I have to understand.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
you've set them to OutputOpenDrain
<adamgreig[m]>
that means you can drive them low, or let them float, in which case they read either low or high depending on what else drives them
<adamgreig[m]>
so if you set the pin low, it will always read low, and if you set it high, it will either read high or low depending on what else is connected to it
<adamgreig[m]>
you usually need some sort of pull up or pull down resistor with such a setup, and you've not enabled any internal ones, so you probably need one to exist in your actual circuit
<FrreJacques[m]>
Hell yeah, setting them all high before read did the fix!
<FrreJacques[m]>
Spent so much time on that before realizing I might use the pins wrong.
<adamgreig[m]>
it wouldn't be reversed, open-drain always means "actively driven low, floats when set high so can be used as an input"
<FrreJacques[m]>
I see, reading a bit in parallel. So I understand how setting low works and I see how setting high isolates it to use it as input.
<FrreJacques[m]>
But how is setting high working for my config? With good luck? I mean it works, otherwise nothing would work.
<FrreJacques[m]>
But maybe I can improve it.
<adamgreig[m]>
usually you'd have a pull-up resistor so that if you set it high, your microcontroller releases the pin but the pull-up resistor makes it a high voltage for other things reading it
<adamgreig[m]>
then anything can drive it low to signal 0, or leave it to signal 1
<FrreJacques[m]>
Okay, I guess instead of adding the resistor I could change the Pull::None part to use an internal one, right?
<thejpster[m]>
I put my R9A02G021 board into UART Boot mode, but the Renesas Flash Programmer won't talk to it. It really does seem dead .... except ... if you put it in UART Boot mode and then pull off jumper J8, LED1 comes on (which is possibly my firmware running). But you still can't program it.
<AlexandervanSaas>
<diondokter[m]> "That's for callers. You may..." <- Is this because of limitations of some flash chips? I tried it with the pico 2 and writing the same byte gives the AND of the previous value and the new value. Wikipedia also mentions that some flash file systems make use of this to store sector states.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
it depends on the flash hardware
<dirbaio[m]>
some only allow writing once to each word (mostly flashes with ECC, because when you write a word you're also writing the extra invisible ECC bits)
<dirbaio[m]>
others allow writing multiple times (and usually the result is the AND yes)\
<dirbaio[m]>
* others allow writing multiple times (and usually the result is the AND yes)
<dirbaio[m]>
and there's more weird shit
<dirbaio[m]>
like nrf52840 only allows writing twice
<dirbaio[m]>
and the weirdest of all: nrf52832 allows 181 word writes for each 128-word block 💀
<dirbaio[m]>
so
<dirbaio[m]>
the base NorFlash trait says "you may only write once"
<dirbaio[m]>
then there's MultiwriteNorFlash that relaxes that restriction