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
> > >
> >
>
