Problem with Compiler update

[mkrummey]

I updated the compiler from 2.1.0 to 2.6.9 and my existing application seems to have lots of issues with Task handling and semaphores. Possibly also issues with software serial port. Were there changes that would effect task or code timing in these areas?

[dkinzer]

I updated the compiler from 2.1.0 to 2.6.9 and my existing application seems to have lots of issues with Task handling and semaphores.

VM or native mode? Can you be more specific about the nature of the problems you're seeing? It will be most helpful if you can distill the code down to the simplest form that still manifests the problem. If that isn't possible, we can also attempt diagnosing the problem using your full application.

If you wish, you can revert to the previous version of the compiler by downloading that version of the compiler using the URL below. It is advisable to rename the more recent files or move them to a different directory before restoring the older ones.
http://www.zbasic.net/download/ZBasic/2 ... _2-1-0.zip

[mkrummey]

I am using a 24a in VM mode. My application is about 30K and has been operating properly for months, even have commercial systems in the field. There are 5 tasks running with a semaphore protecting the use of the COM4 serial port function. I use the SPI port and associated functions for a piece of serial memory. I updated the compiler to be able to use the 1280 for the next system.

The detail for the main clue that I have so far is that after setting a "semaphore=false", the next routine looking for the semaphore got stuck trying to obtain it. (Infinite loop waiting for semaphore to be available.) When I put a debug.print immediately after the "semaphore=false", it started to work! I replaced the debug.print with a delay(.01) which works also.

I still have other issues but it appears that something has changed relative to the Task handler or timing. To verify that my hardware is not a problem, I have downloaded an image of my application which was compiled with the old version and it works as expected.

It is hard to break apart the application in order to simplify it. Any further ideas? Thanks for your response.

[dkinzer]

The detail for the main clue that I have so far is that [...] [w]hen I put a debug.print immediately after the "semaphore=false", it started to work!

This suggests an optimization issue. We may be able to confirm this if you can send me the listing file. If you aren't currently producing one, add a line like the one below to your .pjt file.

Code: Select all

--list=MyProject.lst

[mikep]

The detail for the main clue that I have so far is that after setting a "semaphore=false", the next routine looking for the semaphore got stuck trying to obtain it. (Infinite loop waiting for semaphore to be available.) When I put a debug.print immediately after the "semaphore=false", it started to work! I replaced the debug.print with a delay(.01) which works also.

I have seen this type of problem too although I have assumed up to now that it was "working as designed". I use a semaphore in several places and routines that "serialize" data access look like this:

Code: Select all

Public Sub SomeRoutine()
	' wait for semaphore
	Do While (Not Semaphore(msgSemaphore))
		Call Sleep(0)
	Loop
	
	' guts of routine removed
	
	' release the semaphore
	msgSemaphore = FALSE
	Call Sleep(0)	
End Sub

I use the Sleep(0) to give an opportunity for other tasks to run and grab the semaphore. You are right that the code appears to hang if there is no code after setting the semaphore to false.

This "problem" is not new and I have seen in multiple releases going back to 2.5 or so. I have not tested all the intermediate releases of compiler.