SX52 fuse settings & PC startaddress

simon

Hi!

I have a small (stupid) question:
I was writing some piece of testcode for an SX28
(some leds are flashing).
There everything works fine.

I now have built a small SX52 prototype board and compiled
some source for the SX52.
I am using the SXC C-Compiler.

#define FREQUENCY 20000000
#define FUSE WDTD & FOSC_HS2 // & XTLBUF

#include <dev\sx52bd.h>
#include <port.h>

void main(void){
                PORTB = 0b10101010;

                while(1){
                }
}

This code generates a fuse value of 0xEF9.
Is this correct when i use a normal crystal connected to osc1&osc2 (including 2c's and 1M R) ?

The leds do not light up on the sx52 (connected as on the sx28 where it was working).
The whole board draws 80mAH with MCLR=low (stopped) and 99mAH with MCLR=high (running)
(only the sx52, max232, and a small voltage regulator).
After some minutes the chip is becoming a little bit warmer than room temperature.

The Problem is:
I am using dlscenix for the programming part.
Normally it is designed for the sx28, but i changed something in the firmware
to support the sx52 (as soon it is working i will send the patches to the dlscenix author [noparse];)[/noparse] ).
So i do not know if my problems have to do with
a1) the prototype board
a2) is the 1MOhm resistor beetween the crystal pins correct
b) wrong fuse settings
c) bug in programming sw
d) do i need to set fusex ?

Can somebody here tell me where the PC starts on reset ?
I read 0xFFF in the sx52 datasheet but SXC generates code
with reset vector at 0x1FFF.

The generated hexfile for the above code is:

:020000040000FA
:04000400550C260071
:08000800040A0D0010000509B7
:040010001000020AD0
:021FFE00060AD1
:08202000F90EFF0F002D310144
:00000001FF

The dlscenix writes all data except this line directly to the sx52:
:08202000F90EFF0F002D310144

This line tells me that the is fuse=0xEF9, fusex=0xFFF (frequency=20000000).
The fuse is set correcty by an appended FUSE_CMD.
I can read out the value back.

Thank you very much for any Hints [noparse];)[/noparse]

Bye, Simon

Bean

I don't know if you just left it off of the post, but I don't see where you are setting the TRIS_B register to make the pins outputs.

Reset vector is at 0xFFF for the SX48 & SX52 and 0x7FF for SX20 & SX28

Terry

James Newton

Dude, that question is neither small nor stupid.

The only way I can think of to debug that is to have an SXKey and compare results between the two programmers.

Best of luck, but I think you will need it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

simon

Oh sorry, it was a copy'n'paste mistake.

The right code:

#define FREQUENCY 20000000
#define FUSE WDTD & FOSC_HS2 // & XTLBUF

#include <startup.h>
#include <dev\sx52bd.h>
#include <port.h>

#define PORTB_STARTUP_DDR  OOOOOOOO
void main(void){
                PORTB = 0b01010101;

                while(1){
                }
}

(i removed some code from my testings and wiped out the direction settings)

and the right hex:

:020000040000FA
:04000400550C260071
:08000800040A0F0C4300000C78
:0800100006000D0010000509B7
:040018001000020AC8
:021FFE000A0ACD
:08202000F90EFF0F002D310144
:00000001FF

Could anyone post a sx52 hex file ?
The program itself does not matter.
I just want to compare something.
I might have an idea what is going wrong.

Thank you Bean for the reset location!
i thought it was 0x1FFE and 0x0FFE ...
I will check the programmers firmware.

Bye, Simon

Bean

Here is a sample from SASM.

Bean

simon

Hi!

Thank you very much for your example !

The leds are now on (see attached picture)

So my modifications to the programmer firmware seem
to be ok.

The problem seems to be the hex file generated
by sxc or their fuse settings.

what is the correct fuse for a normal crystal (these silver things with two pins) @20mhz ?

Bye, Simon

simon

Hi!

Ok, now i have my nightrider testcode working

I found out that the code has a problem with the sxc style
of setting PORTB to an output.
The sxc way:

mov    w,#0Fh
mov    m,w
mov    w,#00h
mov    !PORTB,w

if i replace it with

mov !PORTB, #0

everything works ...
I think it has to do with their way of setting the MODE...
I read something that a sx52 needs this workaround with 0F->w->mode

Bye, Simon

Stephen

You shouldn't use the MODE instruction with the SX52 as it only has a 4-bit operand. Moving a value to the MODE register via W will write all 5 bits that are necessary with SX48/52.

simon

Hi!

Thank you Stephen, that is what i have read somewhere.

For me it looks like that this is what the sxc generated code does, or am i wrong ?

mov    w,#0Fh
mov    m,w
mov    w,#00h
mov    !PORTB,w

But when i use this code to set portb as output it does not work.
The leds stay dark.

Bye, Simon

Stephen

It should be writing 1Fh to the M register. 0Fh on the SX52 is the read register for the port direction, 1Fh is the write register. On the SX18/20/28 there was only the capability to write the M register and this was at address 0Fh. In Scenix' infinite wisdom the M values for writing the register was not the same across the families.

It sounds like the SXC compiler is not really designed for the SX52?

simon

Hi!

Ah I think thats it!

Bytecraft says that their compiler has support for sx52.
I was wondering that i have had to add the PORTD direction setting
macros by myself.

I changed the line in Include/ports.h from
#define M_DDR 15 /* m value for data direction register */
to
#define M_DDR 0x1F /* m value for data direction register */
and now the asm file looks better.
I will test it tomorrow on the prototype board [noparse];)[/noparse]

Thank you very much!

Bye, Simon

mendoai

Hi all:

I·did testcode for an SX28 and tested with an SXKey & SXC C-Compiler.
Until there·works fine.

I now have built a small SX52 prototype board and compiled
the same source for the SX52,but·when I want to debug the code in walk mode or step I·received this message·SXKey software· :

·ERROR! Debug requires the following
-2 free words on the first page
-136 free word at the end of the last page
-RESET jump at the end of memory
-Watchdog disabled

·In the SX52 header have:

#define ROM_SIZE 0x1000 /* 4K words of program memory */

In the SX28 header have:

#define ROM_SIZE 0x800 /* 2K words of program memory */

If I change this ROM size in the SX52 equal to 28,the errors dissapear ,and appears the debug windows· but in mode running..

The Bytecraft support is very poor and dont have an answer for this item.

Thanks in advance

Tony Leyland

Hi Simon,

That's a very nice PCB you have there.· This is a bit off-topic, but did you make it yourself or did you have
it done professionally ?· I ask this as I'm trying to give my PCBs that green look like yours (or red or blue).
I understand it is called a "Solder Resist" or something.

Does anybody know how to give PCBs this look ?

Many thanks

Tony

PJMonty

Tony,

PCBs typically start with a fiberglass board that is tan. The green color (as you mentioned) comes from the solder mask. It's job is primarily to keep solder off the board (except for the pads) when a board is mass produced and wave soldered. Wave soldering is basically a tank of solder that the board is skimmed across. Solder mask does come in many colors, but most PCB companies won't give you a choice unless you order a bunch of boards. Green is the standard color.

Thanks, PeterM