28X1 A.0 / 5.1.3 Large Program Size Problem

Tom2000

Senior Member
I posted this in another thread, but it seems to have gotten lost in the noise. A timely solution is of some importance to me, so I'm posting this message (and followup test info) in its own thread.

========

Say, Technical, while I have your ear, I'm having some problems with an ambitious routine I'm writing on an A.0 28X1. You can take a peek at the project here: <A href='http://www.mindspring.com/~tom2000/picaxe/picaxe.html' Target=_Blank>External Web Link</a>

I'm at about 2100 bytes of download code, and I seem to be hitting some sort of code size hard limit. At this point, I have to comment out some code in order to get any new code to load without crashing the processor or entering a permanent 3-second processor reset cycle. (And it doesn't seem to matter what code I comment out. It looks like I just need to free up some space for the new code.)

Matter of fact, even adding a sertxd debugging statement or two is enough to drive the processor into instability.

I'm not at the subroutine limit -- I have only about 30 subs -- and limiting the scope of the program flow with do : loop breakpoints, I know I'm not pushing the 8-deep subroutine call limit.

And when I say that I'm limiting the scope of the program flow, I really mean limit:

<code><pre><font size=2 face='Courier'>



Main:

pause 100

gosub InitLCD
gosub Init1302

gosub SignonMessage

do
loop

pause 2000

gosub ClearDisp
gosub GetTime
gosub ShowTime

Mode = Idle


do

if ModeBtn = 0 then ; Mode btn

etc, etc, etc...



</font></pre></code>

I haven't gone too far toward troubleshooting the problem, but wonder if this is symptomatic of the 28X1?

I'll post the problem code on the page referenced above. Look for a link near the top of the page, right under the page title, which says &quot;Problem Code.&quot;

I'd appreciate any help you might provide. I'm at the end of my rope.

==============

Followup:

I've modified the program to run on the simulator, including removing all the commenting-out. Check syntax shows that it's a bit over 2200 bytes in size.

(I've posted the modified version on the page reference above, also.)

Needless to say, it runs on the sim (except for the &quot;pins =&quot; and &quot;inc b0&quot; stuff), for a while, anyway. After running for some time, the pin1 line decides that it wants to be an output, asserted high. But at least I'm able to run the sim long enough to demonstrate to myself that the code works.

BTW - I have a second A.0 28X1 chip, and the symptoms are the same for both chips.

Again, I appreciate any help, tips, or direction you might provide. Right now, I'm dead in the water.

Thanks!

Tom

 

Technical

Technical Support
Staff member
Your post is a little confusing, are you talking about the real PICAXE chip or the simulator or both as you seem to refer to both at different times!

Your program won't run in 5.1.3 simulation due to a known issue, but will work in our test version of 5.1.4 which will be released soon.

Also your A.0 switches to add ( ^ ) is a 5.1.3 compiler issue (not firmware), which is resolved in 5.1.4. So you won't need the options at all in 5.1.4

So please clarify any issue on the real PICAXE chip?
 

Tom2000

Senior Member
Thanks, Technical, sorry about the confusion. Maybe I should have posted two messages.

The first part of the message discusses problems I'm having with the real hardware. Although the compiler isn't telling me that I've reached a size limit, the processor's behaviour suggests that some sort of program size issue is causing a fault.

The program runs fine, up to a point just short of the code I've posted. Addition of any code at all, or even a couple of sertxd debugging statements, causes the processor to either crash outright or enter the dreaded 3-second endless reset cycle.

I've tested, using do : loop breakpoints to limit program flow, to make sure I'm not exceeding the 8-deep subroutine call limit.

To add more code to my program, I must first delete or comment out some existing code, apparently in order to make room for the new code. It doesn't seem to matter what code I comment out, just that I make some more room in program memory. And the processor doesn't need to execute any code to cause a problem. My breakpoints show that simply the presence of the code in program memory, even if not executed, causes the crashes.

The second part of the message deals with my efforts to understand the cause of the problem. I modified the program so it would run in the 5.1.3 simulator, and removed all my #rem .. #endrem statements so the sim would run all the code that the 28X1 chip wouldn't. After working around the known sim bugs, the program ran fine in the sim. Neither he sim nor the syntax check warned me that the program was oversize, and the modified program ran OK in the sim.

So, the bottom line is this: somehow or other, it appears that I've reached some sort of size limit in the physical 28X1 hardware. It won't let me load a program (well, it won't let me load the program I'm writing) any larger than the one posted in my &quot;Problem Code&quot; link.

Whew... I hope I haven't confused you further!

Many thanks for your attention and assistance.

Tom


Edited by - Tom2000 on 04/07/2007 15:29:22

Edited by - Tom2000 on 04/07/2007 15:36:09
 

Technical

Technical Support
Staff member
You have plenty of memory space left , up to 3840 should be fine (4096 - 256 reserved for the table). Many people have used programs longer than this without any other reported issues.

We will try to look into this further for you.
 

Jeremy Leach

Senior Member
I'm using a 28X1, firmware A0. No Table used. The code size after download is reported at 4030. The syntax chec mysteriously reports 3840.
 

Technical

Technical Support
Staff member
'Check syntax' does not know which firmware you are using as it does not check for a connected chip. It therefore assumes the latest version. However, if you are using A.0, upon download the Programming Editor adds a few bytes to certain commands to correct a small firmware issue.

If you want the Check Syntax to show the result including these extra bytes for A.0 firmware chips, there is a workaround by temporary renaming the compiler files found in the \compiler sub-folder.

First rename the compiler file axe28x1.exe to axe28x1.backup, and then rename the file axe28x1_0.exe to axe28x1.exe.
 

Tom2000

Senior Member
Is the 'Downloaded xxxx bytes' message accurate? If so, we don't need to mess with renaming files to get an accurate count from Check Syntax.

 

Technical

Technical Support
Staff member
'Downloaded' is always correct regardless - the fix above is just for jeremy to match 'Syntax Check' to 'Downloaded'
 

Jeremy Leach

Senior Member
Thanks Technical, I will apply that workaround - I use syntax check a lot just to keep an eye on codesize. Downloading just to check code size is a bit of a yawn at this size of program <img src="wink.gif" width=15 height=15 align=middle>
 

Tom2000

Senior Member
Technical, I have the same problem when I load the program with 5.1.4.

Tom


Edited by - Tom2000 on 06/07/2007 21:20:01
 

Technical

Technical Support
Staff member
We found no issue with your code, it appeared to download correctly for us.

We didn't have the hardware setup as you have for a full test to see if the program is actually correct, but it downloaded and read back as expected.

We are not aware of any large memory issues, many people are using larger programs than yours without problem. In fact your program (excluding table commands) uses less than half the available memory!

Edited by - Technical on 06/07/2007 22:59:58
 

Tom2000

Senior Member
That's very interesting, Technical. Well, before I abandon the 28X1 completely, I'll investigate further.

Thanks for your efforts.

Tom
 

Tom2000

Senior Member
Technical, I just took a look at the listing I posted, and notice that version has some code commented out so the program will run. When you ran your tests on my code, did you remove the #rem and #endrem statements?

Tom
 

Tom2000

Senior Member
Also - you can comment out the

#define A0_firmware directive. 5.1.4 fixed the Out7 problem that was correcting.

 

Tom2000

Senior Member
Technical, I did some more testing, with no progress.

First, taking the HVWTech Stack module out of the equation, I installed an A.0 28X1 directly on the breadboard. Standard download circuit, 5.6k to +V on the reset, 16 uF tantalum between pins 19 and 20, 5.0630 volts Vcc.

I loaded the &quot;Problem Code&quot; file that I posted for you. (I commented out the #define Ao_firmware line.) It ran OK with the two sections of code commented out.

I deleted the #rem / #endrem for the first commented-out block. Processor crashed.

I re-commented that section, then removed the #rem / #endrem lines for the second commented-out block. Processor crashed.

Remaining in that condition, I placed a do : loop breakpoint right after the gosub SignonMessasge in Main. Processor crashed.

When you did the testing whose results you reported simply as &quot;it ran for us,&quot; did you re-activate either or both of the commented out sections?

Also - you mentioned that &quot;you didn't hook up the system.&quot; Of course, I didn't expect you to duplicate my hardware. However, without any sort of output connected to your 28X1, how did you verify that the processor was actually running, and hadn't crashed?

I suspect that all you did was see the &quot;Download Successful&quot; message and say, &quot;OK.&quot;

I suggest that you add some code to flash a LED or something, just to verify that the program is actually running after you place either of the commented-out blocks back in service. (Ports c6 and c7 wouldn't affect the operation of my program at this stage of its implementation.)

Please let me know what you learn. Your report of &quot;it runs fine&quot; gives me no confidence that you've actually attempted any real testing.

Tom


Edited by - Tom2000 on 07/07/2007 17:15:03
 

Technical

Technical Support
Staff member
Naturally we tested your program by adding a couple of LED high/low lines (and editing some the 'if porta pin' lines to 'if variable '), otherwise we wouldn't of known whether the downloaded program ran or not (not having your exact hardware)!

However we may not have removed all the rem statements as you have pointed out, so will test again later.
 

Tom2000

Senior Member
Technical, here's a combination that puts the A.0 28X1 into a constant reset cycle.

First, leave that block that begins near line 319 commented out.

Then comment the block beginning near line 552 as shown below.

Tom

<code><pre><font size=2 face='Courier'>



; #rem
; gosub CheckPwrBus

if Mode = Idle then
gosub GetSecs
if b0 &lt;&gt; PrevSecs then
PrevSecs = b0
gosub GetTime
gosub ShowTime
#rem
if ExtPwrFlag = 0 and BattState = 1 and BLCounter &gt; 0 then
dec BLCounter
if BLCounter = 0 then
gosub BacklightOff
endif
endif
#endrem
endif
endif
; #endrem



</font></pre></code>
 

Technical

Technical Support
Staff member
Sorry for the length of time required to investigate this issue, it was very complicated! We have identified a minor 28X1 compiler software issue that can occur only in rare instances, as with this program with multiple sub-procedures in specific memory locations. We are working on a compiler fix and hope to have it released soon. It is unrelated to the firmware version.
 

Tom2000

Senior Member
YAYYYY!

Technical, I wish you could see the big smile on my face right now! It's just wonderful news that you were actually able to find the cause of the problem. I was so afraid that I'd receive an &quot;it runs fine on our system&quot; response. That would have me tearing out the little remaining hair that I have. :)

I'm absolutely delighted that you'll be able to fix the problem. Great work, and congratulations to you and to your whole team.

Tom

 

Technical

Technical Support
Staff member
Can you send your email address to picaxeATrev-ed.co.uk and we'll send you a beta compiler to try.
 

Tom2000

Senior Member
No problem. I've already posted it in this forum, so no need to back channel it.

tom2000 at mindspring dot com

Many thanks!

Tom
 
Top