Hrm. I do believe that works, though I admit I dont understand it at all.
Chasing a bunch of other problems while I confirm though.
Perhaps a radio comitter can chime in?
After an erase command the device disconnects (as expected as during the
flash erase the ble radio isnt serviced) and the logs say it successfully
returns to advertising, but it never shows up. (bleprph and blesplit
standard upstream)
Oddly If I break and step through bleprph_advertise it does advertise, so
its like a timing issue, the radio isnt ready yet or something...
On Fri, May 26, 2017 at 4:42 PM, Simon Ratner <si...@proxy.co> wrote:
> Sorry, not what i meant at all (I get terser as midnight approaches, ha!)
>
> You are only reading 64 bytes from flash, which is 16 32-bit ints, so your
> result is entirely expected. The rest of the data array is uninitialised.
> Correct code would look something like this:
>
> uint32_t data[64 >> 2];
> ...
> bytes_to_read = min(64, fa->fa_size - data_off);
> flash_area_read(fa, data_off, data, bytes_to_read);
> ...
> for (i = 0; i < bytes_to_read >> 2; i++){
> if (data[i] != (uint32_t) -1) {
> goto not_empty;
> }
> }
> for (i = i << 2; i < bytes_to_read; i++) {
> if (*(((uint8_t *) data) + i) != (uint8_t) -1) {
> goto not_empty;
> }
> }
> ...
>
>
>
> On Fri, May 26, 2017 at 11:09 AM, Jacob Rosenthal <jakerosent...@gmail.com
> >
> wrote:
>
> > Just trying to cargo cult what chris said. whats appropriate? uint32_t?
> >
> > Could be related, but what Im seeing is
> >
> > data after flash_area_read before erase
> >
> > (gdb) p data
> > $1 = {3735928559 <repeats 30 times>, 126616, 46299, 1, 45733, 1, 145408,
> > 112640, 112640, 128076, 103483, 1, 127960, 536872908, 43465, 4294967295,
> > 4294967295, 4294967295,
> > 4294967295, 1, 536872908, 4294967295, 43503, 1, 127960, 127948,
> > 536872908, 127960, 536872963, 112640, 536872960, 46289, 109467, 103572,
> > 16777728}
> > (gdb) p data
> > $2 = {2532554812, 36, 32, 860, 18, 0, 0, 0, 536887296, 145449,
> 4085258752,
> > 4085286932, 553879568, 1744979993, 1610760970, 1744979992, 3735928559
> > <repeats 14 times>, 126616,
> > 46299, 1, 45733, 1, 145408, 112640, 112640, 128076, 103483, 1, 127960,
> > 536872908, 43465, 4294967295, 4294967295, 4294967295, 4294967295, 1,
> > 536872908, 4294967295, 43503, 1,
> > 127960, 127948, 536872908, 127960, 536872963, 112640, 536872960, 46289,
> > 109467, 103576, 1090519552}
> >
> >
> > data after flash_area_read after erase
> >
> >
> > $2 = {4294967295 <repeats 16 times>, 536874064, 536874068, 536883092,
> > 536873880, 0, 38233, 536883088, 536874048, 536874048, 536873534,
> 536876440,
> > 111639, 2, 536874048, 126612,
> > 46299, 1, 45733, 1, 145408, 112640, 112640, 126612, 46299, 32, 45733,
> 32,
> > 145408, 32, 0, 536873624, 103483, 32, 0, 536873688, 108847, 1, 127956,
> > 536883076, 536878212,
> > 127956, 536873687, 2, 127968, 46289, 109155, 103576, 1090519552}
> > (gdb)
> >
> > seems like it successfully erases only 16 uint32s
> >
> >
> > On Thu, May 25, 2017 at 11:49 PM, Simon Ratner <si...@proxy.co> wrote:
> >
> > > At a glance, you are confusing bytes with ints (data is declared as
> > > unsigned int), so for the most part you are comparing uninitialised
> stack
> > > memory.
> > >
> > > Hth,
> > >
> > > simon
> > >
> > > On Thu, May 25, 2017 at 11:04 PM, Jacob Rosenthal <
> > jakerosent...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Pushed something like you described, new flash_area_is_empty function
> > in
> > > > flash_map
> > > > https://github.com/apache/incubator-mynewt-core/pull/281
> > > >
> > > > Currently doesnt actually work.. either my code sucks or the erase
> > doesnt
> > > > actually ever succeed on nrf51 is is leaving behind non 0xff bytes..
> > not
> > > > sure which
> > > >
> > > > On Tue, May 16, 2017 at 5:26 PM, Christopher Collins <
> ch...@runtime.io
> > >
> > > > wrote:
> > > >
> > > > > On Tue, May 16, 2017 at 05:11:36PM -0700, Jacob Rosenthal wrote:
> > > > > > Seems like it could go in flash_map?
> > > > > >
> > > > > > Its also been requested to also have a function that detects if
> an
> > > area
> > > > > > should be erased, based on it having any non 0xff bytes within.
> > > > > >
> > > > > > Should that go there as well.
> > > > >
> > > > > That is the same thing, isn't it?
> > > > >
> > > > > > Whats a good method to loop through all bytes of a flash area?
> > > > >
> > > > > Perhaps something like the following:
> > > > >
> > > > > 1. Allocate a buffer that is properly aligned to be accessed by an
> > > > > unsigned int*. It may take some testing to
> > > > > determine a good size that balances speed and size efficiency; I
> > would
> > > > > start with 64 bytes. I would also start by putting this buffer on
> > the
> > > > > stack.
> > > > >
> > > > > 2. Read a chunk of flash into the buffer
> > > > > (min(size-of-buffer, num-unread-bytes).
> > > > >
> > > > > 3. Use an unsigned int* to iterate through the buffer. If the
> > pointer
> > > > > points to something other than (unsigned int)-1, then the flash is
> > not
> > > > > erased.
> > > > >
> > > > > 4. If there are any remaining bytes (i.e., number of bytes read is
> > not
> > > a
> > > > > multiple of sizeof(unsigned int)), compare them individually
> against
> > > > > 0xff using a uint8_t*.
> > > > >
> > > > > Chris
> > > > >
> > > >
> > >
> >
>
