AtoMMC update firmware

emulators, hardware and classic software for atom + system machines
User avatar
CMcDougall
Posts: 7049
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

AtoMMC update firmware

Post by CMcDougall » Sat Feb 06, 2016 9:36 pm

after reading this thread:
viewtopic.php?f=44&t=10517#p127498
I thought would update mine, now wish I did not..... #-o
before I was on this v2.9:
fw29.jpg
then put (from the thread link above) v2.A:
fw2A.jpg
but, now when I *CAT / *. it just crashes, but */MENU still works :-k

do I need to update the PIC aswell? (which I don't have the programmer for :( )
if this, then where can I get the older v2.9 from?

or is there something else I need to do to get v2.A to work properly

Thanks in advance :wink:
ImageImageImage

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sat Feb 06, 2016 9:51 pm

CMcDougall wrote: do I need to update the PIC aswell? (which I don't have the programmer for :( )
if this, then where can I get the older v2.9 from?
What PIC chip do you have? 18f4520 or 18f4525? If the 18f4520, that may be the issue.

You have just updated the PIC firmware from 2.9 to 2.A.

You now need to update the AtoMMC ROM to the latest (2.98 I think) from here:
http://www.stardot.org.uk/forums/viewto ... =44&t=6596

Dave

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sat Feb 06, 2016 10:07 pm

Actually, ignore my previous post.

I think we've been down this path before:
http://www.stardot.org.uk/forums/viewto ... 40#p102371

I just don't remember the resolution.

Dave

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sat Feb 06, 2016 10:24 pm

I think the resolution was to update the bootloader from 2.2 to 2.9, which is detailed in this post:
http://www.stardot.org.uk/forums/viewto ... 61#p102261
Then reprogram the 2.A firmware.

If the worst happens and you brick it, then post me your PIC and I can re-program it in my PIC programmed.

Dave

User avatar
roland
Posts: 3997
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC update firmware

Post by roland » Sat Feb 06, 2016 11:33 pm

Hi Collin,

If you have a normal pic programmer you can download a good working version of the AtoMMC2 firmware from this page: http://diy.acornatom.nl/downloads.html

This is a known problem that I have had about a year ago while I was building my first Atom 2014. Just like Hoglet also mentioned.

Don't worry, we can fix it :)

Greetings,
Roland
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 7:53 am

Guys,

Did we ever really get to the bottom of the *CAT bug, i.e. exactly what the cause was, and why it seemed to be affected by the bootloader version?

As far as I recall, to get the bug you needed:
- the 2.2 boot loader
- the 2.A firmware

Other combinations seemed to be immune:
- 2.2 BL + 2.9 FW
- 2.1 BL + 2.A FW
- 2.9 BL + 2.A FW

We also ruled out the firmware update process in the 2.2 bootloader being broken, by checking the updated PIC in a PIC programmer (see here).

The only other recent discover was a bug in wfnReadDirectory (CMD_DIR_READ) in the PIC Firmware, see:
https://github.com/hoglet67/AtoMMC2Firm ... 7253d9c699
viewtopic.php?f=44&t=9493&p=110905#p110905

This was causing a crash with *CAT in Atomulator, but *seemed* to not be causing a problem on the read AtomMMC. It affects the CMD_DIR_READ PIC command which is only used by the *CAT command and nothing else.

I'm not sure we ever published a updated 2.A firmware that included this fix. (Should we call this 2.B?)

Today I might test out this theory, by reverting to the 2.2 boot loader. My Atom system is feeling un-loved at the moment!

Dave

PS Kees, you made some fixes to the Windows build chain here but I don't thing these are relevant here, because I've been using Linux not Windows, and still hitting the bug.

User avatar
roland
Posts: 3997
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC update firmware

Post by roland » Sun Feb 07, 2016 8:49 am

hoglet wrote: Did we ever really get to the bottom of the *CAT bug, i.e. exactly what the cause was, and why it seemed to be affected by the bootloader version?
No, we didn't. After we found the right combination of boot loader and firmware, our interests moved on to other subjects.
hoglet wrote: My Atom system is feeling un-loved at the moment!
Mine also, but I hope this will change when the tube interface arrives 8)
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
CMcDougall
Posts: 7049
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: AtoMMC update firmware

Post by CMcDougall » Sun Feb 07, 2016 1:10 pm

Roland wrote:This is a known problem that I have had about a year ago
thanks Roland, not just me then! :mrgreen:
Dave wrote:What PIC chip do you have? 18f4520 or 18f4525?
I have the 18F4525 :D
just grabbed a few moments, and done:
1) put on BootLoaderUpdate29, 2 files.BIN onto card, it flashed green /red, then stayed flashing green for ages, so turned off.
2) deleted above from card, put on the v2A atommc25.BIN file, flashed green / red, then stayed flashing green for ages, so turned off.

and...., I did not brick it!! 8)

I now have on *H. : FW v2.A & BL v2.9 :)

but, *CAT / *. still just hangs :shock: , and */MENU still works, so can still play beeb MIA Early Warning game :P

so, must be the AtoMMC2 rom needing updated to >v2.96E :-k (which again, I don't have programmer for :( )
hoglet wrote: My Atom system is feeling un-loved at the moment!
tut tut, spit [-(

Thanks again folks :wink:
ImageImageImage

PhilYoung
Posts: 205
Joined: Sun Jun 12, 2011 5:55 pm
Contact:

Re: AtoMMC update firmware

Post by PhilYoung » Sun Feb 07, 2016 1:28 pm

CMcDougall wrote:
but, *CAT / *. still just hangs :shock: , and */MENU still works, so can still play beeb MIA Early Warning game :P

so, must be the AtoMMC2 rom needing updated to >v2.96E :-k (which again, I don't have programmer for :( )

Thanks again folks :wink:
Hi,

I think when I had the "hanging on *CAT" problem, it would work start to work correctly if you first did a *CWD to a directory that you knew was there, and then a *CWD back to root. It's almost as if that allows something somewhere to be initialised correctly.

I have no idea if that is of any help, I'm still using one of the fixed versions (prior to the BPUT/BGET capability being introduced)

Cheers,

Phil Young

User avatar
CMcDougall
Posts: 7049
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: AtoMMC update firmware

Post by CMcDougall » Sun Feb 07, 2016 1:35 pm

^cheers, but can't replicate that, as just tried *CWD AS , *CAT still same, even back to root..

also just noticed, it now just hangs with my other known working 2GB cards, ie they worked fine before I started all this #-o
I get Error 38 (sometimes 102) & hangs. A few breaks / escape combinations later, and I can *CAT / *. if no Diretories are present, ie just loose files on the root.

when I put in my original old MMC card, it does not hang, but again won't *CAT / *. , but */MENU works :|
ImageImageImage

PhilYoung
Posts: 205
Joined: Sun Jun 12, 2011 5:55 pm
Contact:

Re: AtoMMC update firmware

Post by PhilYoung » Sun Feb 07, 2016 2:27 pm

CMcDougall wrote:^cheers, but can't replicate that, as just tried *CWD AS , *CAT still same, even back to root..

also just noticed, it now just hangs with my other known working 2GB cards, ie they worked fine before I started all this #-o
I get Error 38 (sometimes 102) & hangs. A few breaks / escape combinations later, and I can *CAT / *. if no Diretories are present, ie just loose files on the root.

when I put in my original old MMC card, it does not hang, but again won't *CAT / *. , but */MENU works :|
I'm sure one of the Atom Illuminati will be along in a minute, I'm just PBI trying to keep up,

Good luck,

Phil Young

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 2:41 pm

Hi Col,

Can you try something for me please?

- Remove the SD card
- Hit Break
- Replace the SD card
- Try *CAT

If you get a NOT READY error, just try *CAT a second time

Dave

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 2:43 pm

Hi Dave,
hoglet wrote:PS Kees, you made some fixes to the Windows build chain here but I don't thing these are relevant here, because I've been using Linux not Windows, and still hitting the bug.
IIRC the *CAT problem was due to the code extending the flash memory boundery which made some Wildcard code missing.
All I changed was expanding the flash memory area from 32 kB (&8000) to 48 kB (&C000).

Maybe it's time to publish some new alligned versions 3.00 of the bootloader, firmware and AtoMMC rom.

Greetings
Kees

User avatar
CMcDougall
Posts: 7049
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: AtoMMC update firmware

Post by CMcDougall » Sun Feb 07, 2016 3:21 pm

hoglet wrote:try something for me please?
- Remove the SD card
- Hit Break
- Replace the SD card
- Try *CAT
Certainly can, and yes that does work, *CAT shows as normal!! =D> Thank you!
ImageImageImage

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 3:36 pm

oss003 wrote: IIRC the *CAT problem was due to the code extending the flash memory boundery which made some Wildcard code missing.
All I changed was expanding the flash memory area from 32 kB (&8000) to 48 kB (&C000).
If you could did out any more info on this, I'm appreciate it. I'm starting to thing there are multiple issues that manifest in the same symptom: *CAT hanging.

I'm currently able to reproduce the *CAT hang, but only with a build of the 2.9 Boot Loader that I made (BOOTLD25.bin md5sum 399a2d25.....). If I use the original 2.9 boot loader (BOOTLD25.bin md5sum 2d565de3....) then I don't get the problem.

I think Colin currently has the 399a2d25 version currently.

Now, I can make the *CAT bug vanish completely, just by doing a *CFG 40. Clearing bit 7 of the CFG byte disables the boot loader from checking for firmware updates. So, it seems like something the boot loader does when checking for firmware is subsequently causing *CAT to break. Also, if this were just the wildcard code missing, the CFG change would not fix it.

But I can only reproduce this with my own build of the 2.9 boot loader. The original one does not exhibit the problem.

Kees, you got the window build system working, correct? Can you try to rebuild the 2.9 boot loader from sources on Windows and check the the md5sum of the BOOTLD25.bin file is?

I'm concerned here because we never put the boot loader code under revision control that we have dug ourselves a big hole! I'd really like us to prove we have the source code and build system that will generate a 2.9 BOOTLD25.bin with md5sum 2d565de3.

Dave
Last edited by hoglet on Sun Feb 07, 2016 3:38 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 3:38 pm

Col,

You'll probably find that *CFG 40 fixes your *CAT problem permanently. This disables the boot loader from checking for firmware updates. It's safe to do, as long as you have firmware flashed (which you do).

I really want to understand what's going on here!

Dave

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 3:50 pm

hoglet wrote:Kees, you got the window build system working, correct? Can you try to rebuild the 2.9 boot loader from sources on Windows and check the the md5sum of the BOOTLD25.bin file is?
Hmmmm ..... I'm trying to do this but MPLAB complains about 'not supporting extended mode in the demo version' .....
When I remove --extended in the PICFirmware-build2.bat, I get an error 'mixed extended and non-ectended modes not allowed' so I'm not able to build any file ....... :(

I'll check if I can download a new version which works.

Greetings
Kees

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 4:02 pm

oss003 wrote:
hoglet wrote:Kees, you got the window build system working, correct? Can you try to rebuild the 2.9 boot loader from sources on Windows and check the the md5sum of the BOOTLD25.bin file is?
Hmmmm ..... I'm trying to do this but MPLAB complains about 'not supporting extended mode in the demo version' .....
When I remove --extended in the PICFirmware-build2.bat, I get an error 'mixed extended and non-ectended modes not allowed' so I'm not able to build any file ....... :(

I'll check if I can download a new version which works.

Greetings
Kees
Looks like extended mode is only available for 60 days:
http://www.microchip.com/forums/m80375.aspx

I get the same error.

It actually looks like it's wfnDirectoryOpen that's hanging, not wfnDirectoryRead.

Dave

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 4:05 pm

That's where I was afraid for ..... hopefully uninstalling and reinstalling will give another 60 days.... :wink:

Greetings
Kees

User avatar
CMcDougall
Posts: 7049
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: AtoMMC update firmware

Post by CMcDougall » Sun Feb 07, 2016 4:11 pm

Doing the *CFG 40 does indeed let me *CAT with MMC card already in on hard-reset (power on) and Break! =D> =D> =D>
Just found my other 4GB sd card with Dragons lair on it, and that also still works too!

Cheers again, Col.
ImageImageImage

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 5:43 pm

Kees, Charlie, and any other PIC experts....

I'm a bit closer to the root cause of this but need some help!

The *CAT hang is happening because the worker function wfnDirectoryOpen is never actually called. It's not that the PIC Firmware has crashed, it's just for some reason not calling that one worker, which is why everything else is fine.

Now, if I look at the .map file, what's special about the WFN_DirectoryOpen worker is it's value is 0.

Code: Select all

        WFN_DirectoryOpen   0x000000       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
        WFN_DirectoryRead   0x000002       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
     WFN_ExecuteArbitrary   0x000018       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
            WFN_FileClose   0x000012       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
           WFN_FileDelete   0x000014       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
          WFN_FileGetInfo   0x00000c       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
          WFN_FileOpenRAF   0x00000a       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
         WFN_FileOpenRead   0x000006       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
        WFN_FileOpenWrite   0x000008       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
             WFN_FileRead   0x00000e       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
             WFN_FileSeek   0x000016       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
            WFN_FileWrite   0x000010       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
     WFN_GetSDDOSImgNames   0x000026       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
         WFN_OpenSDDOSImg   0x00001a       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
        WFN_ReadSDDOSSect   0x00001c       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
 WFN_SerialiseSDDOSDrives   0x000022       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
       WFN_SetCWDirectory   0x000004       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
      WFN_UnmountSDDOSImg   0x000024       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
  WFN_ValidateSDDOSDrives   0x000020       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
       WFN_WriteSDDOSSect   0x00001e       data     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.h
(at least, I think that what that means). WFN_DirectoryOpen must be a pointer to the actual wfnDirectoryOpen code, which is at

Code: Select all

         wfnDirectoryOpen   0x00723e    program     extern /home/dmb/atom/AtoMMC2Firmware/atmmc2wfn.c
Now, if I add a dummy worker ahead of WFN_DirectoryOpen, then the *CAT hang bug goes away.

I've been looking hard at the worker dispatch code in atmmc2core.c:
https://github.com/hoglet67/AtoMMC2Firm ... mmc2core.c

I've added some debugging using the 8-bit port (LATB) so I can see which bits of code get hit.

Code: Select all

       worker = NULL;
        LATB = 0;
        LATB |= 1;
...
            if (received == CMD_DIR_OPEN)
            {
               // reset the directory reader
               //
               // when 0x3f is read back from this register it is appropriate to
               // start sending cmd 1s to get items.
               //
               worker = WFN_DirectoryOpen;
               LATB |= 2;
            }
...
   LATB |= 4;
   if (worker)
   {
     LATB |= 8;
      worker();
     LATB |= 128;
   }
...
void wfnDirectoryOpen(void)
{
     LATB |= 16;
	// Separate wildcard and path 
	GetWildcard();
     LATB |= 32;
   
	res = f_opendir(&dir, (const char*)globalData);
     LATB |= 64;

   if (FR_OK != res)
   {
      WriteDataPort(STATUS_COMPLETE | res);
      return;
   }

   WriteDataPort(STATUS_OK);
}
What I see in the case of a *CAT hang is the port ends up with the value &8F (10001111)

So it looks like worker() is either invoking the wrong worker, or somehow not invoking a worker at all.

I've looked at the PIC assember, and am struggling to make sense of this:

Code: Select all

008826   6a02     CLRF      [0x2]                  worker = NULL;
008828   6a03     CLRF      [0x3]
...
008836   0100     MOVLB     0x0                           worker = WFN_DirectoryOpen;
008838   5100     MOVF      0x0,0x0,0x1                                                                                     
00883a   6e02     MOVWF     [0x2]                                                                                           
00883c   5101     MOVF      0x1,0x0,0x1                                                                                     
00883e   6e03     MOVWF     [0x3] 
...
008b34   5002     MOVF      [0x2],0x0         if (worker)
008b36   1003     IORWF     [0x3],0x0                                                                                       
008b38   e00b     BZ        0x8b50                                                                                          
                                              {
008b3a   868a     BSF       0x8a,0x3,0x0        LATB |= 8;
008b3c   eb02     MOVSF     [0x2],0x44           worker();
008b3e   f044                                                                                                               
008b40   eb03     MOVSF     [0x3],0x45                                                                                      
008b42   f045                                                                                                               
008b44   c045     MOVFF     0x45,0xffa                                                                                      
008b46   fffa                                                                                                               
008b48   0100     MOVLB     0x0                                                                                             
008b4a   5144     MOVF      0x44,0x0,0x1                                                                                    
008b4c   0014     CALLW                                                                                                     
008b4e   8e8a     BSF       0x8a,0x7,0x0        LATB |= 128;
                                              }
[/code]
I'm struggling to understand this code, because I've never dipped into PIC assembler before.

Ignore the BSF, they are my debugging.

I did wonder if the problem was the if (worker) test. But the debug port shows bits 3 and 7 are set, so the body of that if was entered.

Maybe the pointer value in WFN_DirectoryOpen has somehow got overwritten.

Help!!!!

Here's the map and lst files:
confused.zip
(194.33 KiB) Downloaded 38 times
Dave

I still have no idea why *CFG 40 fixed this issue.

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 6:23 pm

Dave,

I managed to create the bootloader v2.2 files.
Can you confirm if these are right?

Greetings
Kees
Attachments
BOOTLD.zip
(7.4 KiB) Downloaded 29 times

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 7:08 pm

oss003 wrote: I managed to create the bootloader v2.2 files.
Can you confirm if these are right?
Hmm, they don't match the md5sum of the v2.2 that's in the wild.

Maybe the compilers have changed, so this might be a red herring.

Here are the md5sums from versions that were released by Charlie:
2.1 - 3e8de7c1....
2.2 - 4b647b09....
2.9 - 2d565de3....
and my Linux build of 2.9 is: 399a2d25

Maybe you could try a window build of 2.9 and see what you get.

Dave

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 7:14 pm

This one differs 1 byte with Charlie's v2.1 and that could be v2.2

Code: Select all

C:\temp\atommc>fc /b bootld25.bin bootld25.org
Bestanden BOOTLD25.bin en BOOTLD25.ORG vergelijken
0000000E: 01 02
BOOTLD25.bin is the version I build and BOOTLD25.ORG is Charlie's v2.1

Kees
Attachments
BOOTLD.zip
(4.93 KiB) Downloaded 28 times

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 7:40 pm

IIRC the bootloader versions 2.1 and 2.2 are the same (except the version nr of course ...)

Code: Select all

BOOTLD25v21.bin                                3e8de7c10ed76aca78bc463b0a890bf9
BOOTLD25v22.bin                                4b647b096a29ba94f820a5529a9eae9e
BOOTLD25v29.bin                                56b04e7dd386123ab340457db672902d
v2.9 looks different, can you send me your source files?

Greetings
Kees
Attachments
BOOTLD25.zip
(7.42 KiB) Downloaded 28 times

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 7:57 pm

oss003 wrote:IIRC the bootloader versions 2.1 and 2.2 are the same (except the version nr of course ...)

Code: Select all

BOOTLD25v21.bin                                3e8de7c10ed76aca78bc463b0a890bf9
BOOTLD25v22.bin                                4b647b096a29ba94f820a5529a9eae9e
BOOTLD25v29.bin                                56b04e7dd386123ab340457db672902d
v2.9 looks different, can you send me your source files?
Try building these - from the AtoMMC 2.9.5 distribution:
Bootloader29.zip
(11 KiB) Downloaded 34 times
Dave

User avatar
oss003
Posts: 3326
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: AtoMMC update firmware

Post by oss003 » Sun Feb 07, 2016 8:08 pm

Yep, v29 has the same Checksum.

Greetings
Kees

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Sun Feb 07, 2016 8:49 pm

I added some serial console logging between commands that prints the values of WFN_DirectoryOpen and WFN_DirectoryRead.

Here's further confirmation that something is corrupting the first couple of locations in RAM.

Code: Select all

Hello!
WFN_DirectoryOpen 723E
WFN_DirectoryRead 7276
Bye!
Hello!
WFN_DirectoryOpen 7200
WFN_DirectoryRead 7276
Bye!
Hello!
WFN_DirectoryOpen 0EA2
WFN_DirectoryRead 7276
Bye!
Hello!
WFN_DirectoryOpen 7285
WFN_DirectoryRead 7276
Bye!
WFN_DirectoryOpen is a function pointer that happens to be stored in locations 0 and 1 of RAM.

This sort of problem is really hard to find without a debugger. :(

I still have no idea why the bootloader looking for atommc25.bin prevents this from happening.

Dave

User avatar
1024MAK
Posts: 10230
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: AtoMMC update firmware

Post by 1024MAK » Sun Feb 07, 2016 8:57 pm

It's not wrap-around is it?

I have not looked at this in any detail, but PIC micro controller RAM has limited direct addressing, and limited relative addressing. When the relevant address goes past the maximum count, you get wrap-around to RAM address zero.

As there is often more RAM in a PIC than can normally be directly addressed, back switching / paging is used. So it is not at first glance obvious what is going on to cause wrap-around.

Mark

User avatar
hoglet
Posts: 9385
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: AtoMMC update firmware

Post by hoglet » Mon Feb 08, 2016 12:36 pm

Hi Guys,

I found the root cause of the problem!!! :D

This is the cause of the corruption of the WFN_DirectoryOpen function pointer:

Code: Select all

/*-----------------------------------------------------------------------*/
/* Mount/Unmount a Locical Drive                                         */
/*-----------------------------------------------------------------------*/

FRESULT f_mount (
	BYTE vol,		/* Logical drive number to be mounted/unmounted */
	FATFS *fs		/* Pointer to new file system object (NULL for unmount)*/
)
{
	FATFS *rfs;

	if (vol >= _DRIVES)		    /* Check if the drive number is valid */
		return FR_INVALID_DRIVE;
	rfs = FatFs[vol];				/* Get current fs object */

	if (rfs) {
#if _FS_REENTRANT					/* Discard sync object of the current volume */
		if (!ff_del_syncobj(rfs->sobj)) return FR_INT_ERR;
#endif
		rfs->fs_type = 0;			/* Clear old fs object */  <<<<<<< THIS WAS CORRUPTING WFN_DirectoryOpen
	}
What's interesting is that line should only execute if there is an existing fs object (i.e. rfs not null). So why is it executing the first time the firmware boots?

Lets look at how FatFs[] is defined:

Code: Select all

static
FATFS *FatFs[_DRIVES];	/* Pointer to the file system objects (logical drives) */
It's defined as a static variable in ff.c. My understanding was that in ANSI C, static variables should initialized to zero, but this looks like it isn't happening. So lets add an explicit initializer to check (in our case we know _DRIVES is 1):

Code: Select all

static
FATFS *FatFs[_DRIVES] = { NULL };	/* Pointer to the file system objects (logical drives) */
And this fixes the corruption. So it looks like a compiler runtime problem not doing initialization properly.

This also I think explains the weird dependency on the boot loader, and on *CFG. If the boot loader happens to use the memory that will in the future become the FatFs array, then this bug surfaces. It's very likely this bug has always been present, but only in the 2.A firmware build is something important at the location being corrupted.

A bit more googling found this:
http://www.microchip.com/forums/FindPost/523191
The ANSI standard requires that all objects with static storage duration that are not initialized explicitly are set to zero. With both the c018.o/c018_e.o and c018i.o/c018i_e.o start-up code modules, this requirement is not met. A third type of start-up module, c018iz.o and c018iz_e.o, is provided to meet this requirement. If this start-up code module is linked with the application, then, in addition to initializing idata sections, all objects with static storage duration that are not initialized explicitly are set to zero.
So the correct fix is to change the linker scripts to link with c018iz.o and c018iz_e.o which is what I have done:
https://github.com/hoglet67/AtoMMC2Firm ... 6da0a09247

And that works as well.

Here's a new build of the firmware (called 2.B now) with the fix:
atommc25_2B.zip
(12.05 KiB) Downloaded 36 times
Just drop this on a blank card and hit break a couple of times (but do check you have the newer PIC 18F4525 first!)

Dave

Post Reply

Return to “acorn atom and acorn system series”