SpinSemi M16_24 project questions

[Rob Strand]

OK, now before I order some parts and the PCB let's summarize:

I checked it all against the datasheet and it looks good.
During my checking I found some other issues.

The PonyProg doesn't specifically say it supports AT89S8253  (only AT89S8252 and AT89S53)

There are posts about it, some quite old like 2008/2009,
https://duckduckgo.com/?q=pony+programmer+AT89S8253&ia=web

I cannot see any resolutions.  I supposed if it worked no one would complain.
However, the fact it isn't on PonyProgs list of supported devices is of concern.

When checking I also noticed the AT89S8252 and AT89S53 are only  5V devices.
So they probably won't work on your board at 3.3V.

What a pain!    The pain comes the from need for DIY a programmer that works.

[Rob Strand]

OK now I'm confused.   I downloaded the C++ source code for the PonyProg.
Inside the file at89sxx.cpp there is code  which is handling processors AT89S8253,
AT89S8252, AT89S51 and AT89S52.

For the processors AT89S51, AT89S52 and AT89S8253 there is an extra test which is
checking something to do with the EEPROM.  This check could fail (I'm not saying it will fail).
Whereas the AT89S8252 has no such check, so there is no potential to fail the check.
It could be checking something simple like some aspect of the device has been locked in some way
on previous programmings so you can reprogram it (or part of it) after that.

I'd have to go digging deeper into the code to decipher the meaning and without
any devices to play with that might take a long time.

I can conclude these possibilities:
- The AT89S8253 is supported.
- The AT89S8253 is in the process of being supported but at this point in time it doesn't work because
  of some pending issues.
- Some AT89S8253's work and some don't.   
- The AT89S8253 is not supported.

We need to find a post or something saying it now works or doesn't work.

[Rob Strand]

In this paper the guy implies he can program an AT89S8253 using PonyProg,
http://es.elfak.ni.ac.rs/Papers/Stepenisni%20automat.pdf

Using PonyProg starts on page 30.  Then on page 33 he says to select AT89C53 from the menu to program the AT89C8253.
Translation: "Slika 19. Selection of the type of microcontroller (AT89C53 corresponds to AT89C8253)"

EDIT 1:
But then I see,
http://www.edaboard.com/thread7930.html
Now the guy might just be reading the menu options to determine what is supported. I don't know.

EDIT 2:  There is hope

http://ponyprog.sourceforge.net/phorum/read.php?2,728,738

[MetalGuy]

In my version of PonyProg  (2.08d Beta  Apr  2 2017) I see AT89S8253 in the list of devices so I'd assume it's supported.

[Rob Strand]

I see AT89S8253 in the list of devices so I'd assume it's supported

OK good.  There was some probably some transitional period where the software changed.
That might explain why there's no recent posts asking about AT89S8253 support.

[MetalGuy]

Digging still going on. It looks like Avrdude supports Pickit2 and can be used to program the AT8938253. Somebody wrote a definition file for it:
http://www.edaboard.com/thread76766.html
Pickit2 to AVRISP pins:
http://www.expkits.com/userfiles/images/urun_foto/pk2avrisp1.jpg
I installed Avrdude added AT8938253 definition it to the CONF file and now it appears in the list of devices (used Avrdudess for GUI). I'll have all parts for the next weekend so first test results are expected in a week or so.

[Rob Strand]

I installed Avrdude added AT8938253 definition it to the CONF file and now it appears in the list of devices (used Avrdudess for GUI). I'll have all parts for the next weekend so first test results are expected in a week or so.

That would be very cool if it works  There's a good chance it will unless the hardware (or software) has something specific that makes it incompatible.

[MetalGuy]

Concerning the code and compiling the hex file now that we choose the AT89S8253 shouldn't the 89S8253.MCU file be included instead of the 8052.MCU?

[Rob Strand]

Concerning the code and compiling the hex file now that we choose the AT89S8253 shouldn't the 89S8253.MCU file be included instead of the 8052.MCU?

It's usually safer to use a specific definition file.    However, I suspect both will probably build (and work).

There's a base-line set of functionality which is common to many processors.   If you only use those common feature's you will find the definition file isn't so critical.   However each processor has it's quirks, a special feature, a special register, an extra timer, banked memory.  It's when you start using these you really need a definition file that is specific as possible.

[MetalGuy]

It looks like the 89S8253.MCU file didn't work and build failed. I compiled an Excel file with 8052, 89S8253 and MOD52 for comparison and from what I can there are see some differences in definitions which I can't tell if they are crucial or not.



Below is a link to the table:

https://ufile.io/ww6bg

Differences (rows number in the table):

14-15
86-88

[Rob Strand]

I see the problem(s).

1) line 33
The 89S8253.MCU uses the name SCK but so does the code. So there is a conflict.

2) The others
89S8253.MCU  doesn't use the symbols dph and dpl.
It uses dp0h and dp0l  ; it does that because has a  dp1h and dp1l so they wanted to make the names clear.

It's probably easier to just use 8052.MCU.

If you really want to use 89S8253.MCU then there's a few ways to do it.   The fixes just create work for you.  If you aren't going to modify the code and take advantage of the 89S8253 features, using 8052.MCU is easier.

So as you can see trying to do the "right thing" often creates trouble!

[MetalGuy]

Using some deduction this is what I did from the top:
1/ Open the asm file in MIDE51 and from Device menu choose 89S8253 (I guess that's what the $include line does?).
2/ Hit F9 (Build). I get the following error:



3/ Since smod52 line is illegal let's delete it and hit f9 again. Now I get the same error less row #4 (the $mod52 line) which is gone.

Scrolling down to 145-147 I noticed that rcap2h, rcap2l and t2con are not declared in the ports and registers sections.



Also I see 0C9H against T2MOD (row146). What if I replaced rcap2h, rcap2l and t2con similarly like this:



4/ Hit F9. HEX file is generated without errors! I don't know if all this is not wrong though.

[Rob Strand]

3/ Since smod52 line is illegal let's delete it and hit f9 again. Now I get the same error less row #4 (the $mod52 line) which is gone.

Scrolling down to 145-147 I noticed that rcap2h, rcap2l and t2con are not declared in the ports and registers sections.
Also I see 0C9H against T2MOD (row146). What if I replaced rcap2h, rcap2l and t2con similarly like this:

You shouldn't have to to do this it's all caused by the smod52 line failing.

You need to removed the smod52 line and replace it with the two lines I mentioned in the earlier part of the thread.  When you fix that everything will work.

[MetalGuy]

Your way works as well

[Rob Strand]

ur way works as well

OK cool.  I guess the main thing is you shouldn't have to modify the code.

1/ Open the asm file in MIDE51 and from Device menu choose 89S8253 (I guess that's what the $include line does?).

I'm not sure what that does.  It shouldn't override $includes.   However, note that the IDE has other modules like the simulator and it might tell the simulator and other components what processors to emulate - that's where you really do care what processor your are running on.

[MetalGuy]

After many hours of reading and testing no luck programming the chip so far. It turns out that this is a very tricky one. After so many experiments with different setups I might as well have damaged it so I ordered couple of more just in case.

[Rob Strand]

After many hours of reading and testing no luck programming the chip so far. It turns out that this is a very tricky one. After so many experiments with different setups I might as well have damaged it so I ordered couple of more just in case.

Hmmm. 
Is it failing during program?  ,or, does it appear to program and the code doesn't run?

If it is the later then make sure the entry point is being set correctly. 

[Rob Strand]

Forgot to ask what, what programming methods did you try?

[MetalGuy]

I tried using Pickit2 which is supported by Avrdude and Ponyprog with a serial adapter as already discussed previously. Also tried several different software packages (I don't even remember the names). It turns out the 8253 the programming sequence (according to the datasheet) is different from 8252 and others from the 89S series. Bottom line is the software failed to communicate with the chip. In PonyProg if I select S53 for example it would read it but it won't write it.
The serial cable I had by hand turned out to be a null modem cable so there's a chance that higher than 5V levels were applied to the chip that's why I ordered two more to eliminate the possibility of trying to program a baked chip. After that a regular cable didn't work either.
I ordered an USBasp programmer for couple of bucks from Ebay which according to forums can do the job but we'll see.
I can find someone who will program the chip for me just to make sure the code is OK but I don't want to quit yet.   

[Rob Strand]

I tried using Pickit2 which is supported by Avrdude and Ponyprog with a serial adapter as already discussed previously. Also tried several different software packages (I don't even remember the names). It turns out the 8253 the programming sequence (according to the datasheet) is different from 8252 and others from the 89S series. Bottom line is the software failed to communicate with the chip. In PonyProg if I select S53 for example it would read it but it won't write it.

Looks like you have been hard at it.

From what I can see the 8253 is closer to the S52.  The 8253 has some extra modes but if you don't use them it looks close.   The other wierd thing is from what we both found is Ponyprog should work.   If the cable is wrong then there's no hope of it working.

If you can *read* the device then the chip might not be fried as the read pin is the one that would get fried.   Having said that I've seen some pretty weird behaviour from fried micro's.   Whatever weird-assed behaviour they throw-up no longer phases me.

The serial cable I had by hand turned out to be a null modem cable so there's a chance that higher than 5V levels were applied to the chip that's why I ordered two more to eliminate the possibility of trying to program a baked chip. After that a regular cable didn't work either.

Hard to predict what will happen after that. 

I ordered an USBasp programmer for couple of bucks from Ebay which according to forums can do the job but we'll see.
I can find someone who will program the chip for me just to make sure the code is OK but I don't want to quit yet. 

Not a bad idea.  No doubt you will get it working.  It only takes one thing wrong to stuff you up.  The trouble is out of the 10 things that could be wrong you have to try to find it.