I am anticipating having more than 600 objects in the A&D storage flash so am using the adl_adFindInit and adl_adFindNext.
Has anyone used these? Its not clear to me exactly how they operate. The adl_adFindInit take a min and max CellID to act as the end stops of the search. If you just want the whole list can you just enter 0 and 0xFFFFFFFE ? I then step through the CellIDs with the adl_adFindNext. This allows me to discoved the first and last entries and the entry count available in the flash on boot.
I’ve tried this and it seems to work the first time (I got 40 entries which is about right). However if I do it a second time to access the data in these entries, do an adl_adFindInit(0,0xFFFFFFFE) , then adl_adFindNext, it seems to start at entry 30. I then successfully get the data of the last 10 entries.
Also the adl_adFindNext seems to not recognise the last entry in the list until it tries a second time, so I get the last entry twice.
The TRACE output of ADL32 gives A&&D subs 388AD59A 56: -4 while the adl_adFindNext return value is 0.
(the 388AD59A is the CellID, the 56 is number of bytes in the Cell and the -4 I presume is an error value, it is the Cell number in the successfull reads) the next time the TRACE is the same but the adl_adFindNext returns ADL_AD_RET_ERR_REACHED_END. The data is the same at the previous one.
Any clues? This flash store is supposed to be finished tomorrow so I can go on holiday!!!
Well, its seems that it was working all the time, its just that the debug output disappeared for the beginning of the process. Both my app TRACE and the ADL 32 outputs from the low level code disappeared for a large portion of the flash read out. I put in a counter to check the number of reads and it says that all the reads were performed.
Anyone else seen debug disappear like this? The flash read might be quite quick, but the system stops after so there is time for the system to catch up if that was an issue.
I don’t know about “like this”, as I haven’t seen what your “this” is “like” - but I have certainly seen debug disappear when there’s just too much of it.
It’s all being transferred over a serial link, so I s’pose there’s only so much that can be buffered-up for it to “catch-up” later - and once stuff is lost, it’s gone for good.
I have found that it helps if you know it’s coming and press the ‘Stop Scroll’ button before it starts; it is then more likely to recover when you scroll again - but this still only works up to a point.
Your only options are either to try to minimise the volume of output (turn off unnecessary traces; abbreviate to the extreme) or implement your own “event log” scheme that you can query at leisure…
I guess you could be right, the debug was only about 80 lines long, but the buffer might well be smaller than this. I might try making the trace output smaller and see if I get more events logged. Cheers.
