Think I found the source code used for the file system used in the scope.
http://elm-chan.org/fsw/ff/00index_e.htmlBecause what are the odds of several functions showing the same things at the beginning, one of which in my book is a no no.
int FUN_800337c4(char **param_1,uchar *param_2,uint param_3)
{
if (param_1 == (char **)0x0)
{
return 9;
}
typedef enum
{
FR_INVALID_OBJECT, //(9) The file/directory object is invalid
} FRESULT;
FRESULT f_open (FIL* fp, const TCHAR* path, BYTE mode)
{
if (!fp)
return FR_INVALID_OBJECT;
uint FUN_80033b18(int param_1,int param_2,uint param_3,int *param_4)
{
*param_4 = 0;
uVar1 = FUN_800390e8(param_1,aiStack44);
FRESULT f_read (FIL* fp, void* buff, UINT btr, UINT* br)
{
*br = 0; //Clear read byte counter
res = validate(&fp->obj, &fs); //Check validity of the file object
The no no is the writing to a pointer without making sure it is valid.
Removed parts of the code not needed for the comparison and cleaned it up a bit. The FatFs code is written in a style I very much dislike. Cluttered and hard to read.
But is makes live easier and all that needs to be done is figure out the low level stuff that is needed on the bottom end of the FatFs code.
Also have a better idea about the firmware upgrade setup. Not sure if it is true and think it could have been done much simpler.
The code reads the header of the firmware image file on the SD card and performs some checks. If found valid the first 1000 bytes of the flash where the program resides is cleared.
Then a reset is forced by the use of the watchdog timer. This triggers the SPL to start loading the code again, but it fails with the loading of the main program because the BROM header is no longer there.
As a result to that, it loads the other program we found in the flash. (When I tried it, some time back, this program set the scope in FEL mode.)
But my guess is that when the SD card holds a valid firmware file it loads that and performs the flash writing to fix the previously cleared part and, at the end of it, restarts the scope again.
When the system file is corrupt it shows this on the scope screen and goes into USB connect mode. This way one can correct the contents of the SD card.
Have not verified this and since there is no firmware file to be found for this device it is also not that simple to check.
It might open up an easy way to update scopes when new firmware has been created. But that still has a long road ahead.
Edit: Realized that for new FPGA content the device needs to be opened up, so in that case it is just as easy to use another method of loading the new code.
![Face Palm :palm:](https://www.eevblog.com/forum/Smileys/default/facepalm.gif)