Fixing the 2.72 8M Issues

Moderators: lily.li, violet, jeremy882, crail.lyu969

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by bobtidey » Mon Feb 24, 2014 6:33 pm

I don't think I had merged all your changes into the Wildcat version of files.c correctly first time round so the sector buffer was still at 512. Now I have redone that I get same behaviour. I can get LARGEST_SECTOR_SIZE up to about 3300 bytes and it behaves OK so it does look like it is a memory issue like you said, but it's not far off. It probably needs the lds files adjusted a little.

I attach my Wildcat files.c for comparison.

The only build environments I have seen for the SYS are the factory ones which use IAR Embedded workbench. In principle it should be possible to do it with the same toolchain as for the APP but I've haven't seen a makefile for that.

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by bobtidey » Mon Feb 24, 2014 9:21 pm

So as a first quick experiment I adjusted the main.lds so that _estack = ORIGIN(ram)+LENGTH(ram)-0x1C00; instead of the default -0x2000. This reduces the stack space from 8K to 7K. I don't think any of the large data structures are put on the stack.

With this change and the LARGEST_SECTOR_SIZE set back to 4096 then Wildcat starts up and seems to run OK although I didn't tested it that much.

There are a few things to think about in the RAM allocation.

When I generate a memory map during linkage of Wildcat it shows RAM usage from 0x20003000 to 0x2000a9c8. That's worrying as I think some of the variables are still overlapping the stack space. The top ones are a few flags and quite a bit of the fft variables. So I think this still not be a good allocation.

There are a number of possibilities here.

The start is set to 0x20003000 which I think is allowing for the bottom 12K to be used by the SYS and I don't think it is using that much so it is possible the start could be lowered a bit.

The other thing is that the memory assumes the 48K RAM present on the processor whereas I think that this is actually 64K in practice. This is a bit like the Flash ROM where it is nominally 256K for this processor chip but in practice 512k is present and usable.

I tried the latter approach as I don't know the top of the SYS memory. I restored stack size to 0x2000 and changed APP1.lds as attached to assume 48K Ram length ( 12-60K)and generated the Wildcat APP01.

That also seemed to work OK and I did a test of the fft with this one which worked OK.

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by bobtidey » Mon Feb 24, 2014 10:13 pm

Based on this memory map extracted from a SYS1.6 8M version project, it looks like highest address used by the SYS is around 0x20001620. This should mean that it would be Ok to move the RAM base of the App down from 0x20003000 to say 0x20001800 freeing up 6K at the bottom end. That would be plenty to accommodate the increased filing buffers within the nominal 48K RAM space.

I haven't tried that yet as I'm comfortable with increasing the top end of the RAM limit.

cory.play
Pre-kindergarten
Pre-kindergarten
Posts: 14
Joined: Thu Feb 20, 2014 4:45 am

Re: Fixing the 2.72 8M Issues - fixed

Post by cory.play » Sat Mar 01, 2014 7:11 am

Bobtidey - Changing the RAM to 48k seems to work as you suggest. As far as I can tell this is now fully functional. I have included the source and updated .HEX files one more time, but do need to find a way to post these somewhere! Since I took out the dependency on the modified SYS, perhaps this version and your "wildcat" version have the same functionality?

So, for anyone watching, you should not be able to use the "community version" with the new hardware.

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by bobtidey » Sat Mar 01, 2014 6:29 pm

It is looking like Community and Wildcat are in reasonable shape for 8MB now. I attach my version of the Wildcat31 with these mod. That includes the modded source (re-organised into same tree as Community) and compiled hexs for slot 1 and 3. I haven't tested them on an 8MB device.

Wildcat and community are both similar being based on the same root code. However, Wildcat version does have additional refinements.

From an 8MB point of view that still leaves the Gabonator main App and Pawn as the larger items.

The Gabonator App is reported to run on 8MB devices but doesn't save / load correctly. The code is completely different from the community App and exploits the extra 256K ROM available to have a nice GUI and build in a lot of extra functionality. It looks like the main change needed for 8MB is to adjust the SectorSize. Currently, this is an enum in the FILEINFO structure and set to 512. This makes it a little awkward to change. As an experiment I just compiled a version with the enum SectorSize set to 4096. This ran out of memory. Checking the map showed that 2 SectorSize buffers seem to be used so the memory needs had grown by 7KBytes. I adjusted the lds to give it 7K more room as there was still space at the top using the 64K actually available. This then compiled OK. I attach this here but again it is untested. If this works then it would be best to put in the device test and make the SectorSize a variable like you did in the Community app. It is slightly less obvious where to put that.

Pawn again is supposed to run on 8MB devices OK but I haven't seen any reports of uses which involve loading and saving to disc. I suspect those would fail on an 8MB device without similar adjustment.

jpa
Elementary-2
Elementary-2
Posts: 215
Joined: Wed Nov 02, 2011 4:06 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by jpa » Sun Mar 02, 2014 4:49 am

bobtidey wrote: Pawn again is supposed to run on 8MB devices OK but I haven't seen any reports of uses which involve loading and saving to disc. I suspect those would fail on an 8MB device without similar adjustment.
Pawn always needs to load files so if it works at all, filesystem access works also. Saving is also reported as working https://github.com/PetteriAimonen/QuadPawn/issues/11

Logic Analyzer saving does not work on 8MB. Pretty simple to fix, but haven't bothered so far. There is a lot that could be improved about logic analyzer and I just haven't felt like doing it.

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by bobtidey » Sun Mar 02, 2014 6:32 am

Thanks. That is good news. One bit of clarification. Does it require the Alter Bios for this to work as there are 8M fixes in that?

jpa
Elementary-2
Elementary-2
Posts: 215
Joined: Wed Nov 02, 2011 4:06 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by jpa » Mon Mar 03, 2014 1:52 am

bobtidey wrote:Thanks. That is good news. One bit of clarification. Does it require the Alter Bios for this to work as there are 8M fixes in that?
QuadPawn always installs non-patch version of AlterBIOS for itself, as it needs it to work at all (on any device, 2M or 8M). The separate AlterBIOS .hex also patches the default bios, but I'm not sure if anyone has tested the patch stuff on 8M. Not much need for it, maybe.

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: Fixing the 2.72 8M Issues

Post by bobtidey » Mon Mar 03, 2014 9:42 pm

Thanks jpa. That's clear for me on Pawn.

Attached here is my attempt to do Gabonator supporting both 2MB/8MB units. It contains the Hex files and the files I changed.

I replaced the constant SectorSize with a new call which returns the SectorSize 512/4096 depending on model, and I changed RAM limits.

This works OK on my 2MB unit. I won't have a chance to try it on an 8MB unit for a couple of weeks.

skyfoggy
Pre-kindergarten
Pre-kindergarten
Posts: 2
Joined: Tue Feb 25, 2014 6:06 pm

Re: Fixing the 2.72 8M Issues

Post by skyfoggy » Tue Mar 04, 2014 7:45 pm

Thank you very much bobtidey for the great work and thank to cory.play also, for starting this post.
I have a very new MiniDSO HW 2.72 with stock SYS and FPGA, Device FW Upgrade 3.12C and with the stock APP it was very limited.
I installed the last wildcat3.1 in slot 1 and the modified gabonator in slot 3. I have to make a better calibration, then I'll start a complete test, but at a first use it looks that all is working fine.

I also have the QuadPawn in slot 4 and it looks it is working well also, but I have intensively tested just the Frequency Response.

Just a note: when I tested the first release from cory.play (AP8MG251_1.hex) I had to rename the application files with a shorter name (AP_1.HEX), otherwise the application was not able to start. I've done the same for the other applications I tested. It can be is is a known issue, but I report it for the newbies like me.

Post Reply