I stated writing a software to monitor a MC68HC908JB8 for linux
http://demaine.free.fr/monitor_68hc08/src/

after compiling the software, i run it and hit:
$ key
$ write 40 0A

see my logbook page 29
http://demaine.free.fr/projet_slef_tracking_webcam/raports/log_book.pdf

you can enter a very verbose mode using argument -VVVV

I do not understand why the chip bugs when sending 0x0A or 0x0D. any
other data work fine, but those 2 values do not work

thank you for any help.

"Doublehp" <dhp@doublehp.org> wrote in message
news:71c62763.0401270812.113d6256@posting.google.com...
> I stated writing a software to monitor a MC68HC908JB8 for linux
> http://demaine.free.fr/monitor_68hc08/src/
>
> after compiling the software, i run it and hit:
> $ key
> $ write 40 0A
>
> see my logbook page 29
> http://demaine.free.fr/projet_slef_tracking_webcam/raports/log_book.pdf
>
> you can enter a very verbose mode using argument -VVVV
>
> I do not understand why the chip bugs when sending 0x0A or 0x0D. any
> other data work fine, but those 2 values do not work
>
> thank you for any help.

I don't pretend to have your answer but 0x0A and 0x0D are line feed and
carriage return ASCII characters. Maybe the monitor is processing these?

Regards,
Ray

"kansas_ray" <kansas_ray@hotmail.com> wrote in message news:<xuxRb.10972$8n5.1894@newssvr24.news.prodigy.com>...
> I don't pretend to have your answer but 0x0A and 0x0D are line feed and
> carriage return ASCII characters. Maybe the monitor is processing these?
> 
> Regards,
> Ray

I am the author of the monitor, so i can sware you the monitor send
the characters using low level routines, and AFAIK I managed the stuff
to send values without wondering if they are CR or NL. And when
reading the documentation of the chip, section serial_monitor, one can
read that values are received as DATA, and shall be read/written
without interpretation.
Thus I still wonder why values do not echo as is.

It might be a hard stuff for you to read the source of my monitor, but
I am pretty sure I am sending hexadecimal 8 bit datas, unless I
misconfigured the serial port.  If you decide to help me, you can read
cmd_write in cmd.c, chip_write in chip.c, and rs232_send in rs232.c;
also have a look at lines 49 to 71 of rs232.c. These are the few
revealant lines envolved in the command write, as described in my
logbook

Thanks

Doublehp wrote:
> I stated writing a software to monitor a MC68HC908JB8 for linux
> http://demaine.free.fr/monitor_68hc08/src/
>
> after compiling the software, i run it and hit:
> $ key
> $ write 40 0A
>
> see my logbook page 29
> http://demaine.free.fr/projet_slef_tracking_webcam/raports/log_book.pdf
>
> you can enter a very verbose mode using argument -VVVV
>
> I do not understand why the chip bugs when sending 0x0A or 0x0D. any
> other data work fine, but those 2 values do not work

You have to be careful when using those characters across a Un*x boundry.
0x0D / 0x0A are Carriage Return / Line Feed pair.  Un*x uses a single 0x0A
as a New Line character, and when it's sent in I/O, it's translated to
CR/LF for the rest of the world.  (Except older Macs which used a single
CR for a NL.)  You probably need to open the device in a "raw mode" that
doesn't use translation.

-- 
Ron Sharp.

"Android Cat" <androidcat99@hotmail.com> wrote in message news:<sxxRb.4581$qU3.260259@news20.bellglobal.com>...

> 
> You have to be careful when using those characters across a Un*x boundry.
> 0x0D / 0x0A are Carriage Return / Line Feed pair.  Un*x uses a single 0x0A
> as a New Line character, and when it's sent in I/O, it's translated to
> CR/LF for the rest of the world.  (Except older Macs which used a single
> CR for a NL.)  You probably need to open the device in a "raw mode" that
> doesn't use translation.

here are lines 49 to 71 of rs232.c, about opening the serial port:

        fd=open(vars->device,O_RDWR | O_NOCTTY | O_NONBLOCK);
        /* same as O_NDELAY */
        if(fd<0){fprintf(stderr,"rs232_open: unable to open serial
port %s\n",va
rs->device);
                close(fd);
                return(-1);
        }

        tcgetattr(fd, vars->serial);       /* get setting of the
serial port */
        cfsetispeed(vars->serial, speed);       /* set in and out
speed */
        cfsetospeed(vars->serial, speed);
        vars->serial->c_cflag |= (CLOCAL | CREAD);      /* Enable the
receiver a
nd set local mode... */
/* set No parity (4 next lines */
        vars->serial->c_cflag &= ~PARENB;
        vars->serial->c_cflag &= ~CSTOPB;
        vars->serial->c_cflag &= ~CSIZE;
        vars->serial->c_cflag |= CS8;

/* canonical raw input */
        vars->serial->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);

        vars->serial->c_cflag |= (CS8); /* use 8bit data */

as you can see, I am using canonical mode with 8bit DATA ( very
important when using unsigned char). I am not sure about the raw mode,
but I expect canonical to be enough; I am perhaps wrong ?

For more information about my code, read 'man termios' ,
http://www.easysw.mike/serial/serial.html
and the source code of SPGMR available from www.sourceforge.net

I want to repeat a last time that I want to use pure hexaddecimal
8bits data.

cannot understand your problem description completely 
and did not read all your pdf files but one thing is shure:

You cannot return from HC08 user code to the buildt in 
monitor using a RTS instruction. The reason is, becouse
the monitor itself invokes your user programm with a 
rti instruction and does not push any return address

To start mon08 jump to the monitor address. This start
address unfortunately depends from mask version. To
determine this address, analyze the vectors of the 
security code table minus a offset (0x100?). See also
the monitor chapter in data sheet. 

For the AZ60 I have the following code in use:

   tsx      ;SP into HX  
   inx 4,x  ;correct program counter by increment
   bne l1
   inc 3,x  ;16 bit increment
l1:lda 0xfefc  ;get monitor vector
   psha  ;user swi vector is @ 0xfffc
   ldx 0xfefd  ;get monitor start lowbyte
   jmp 0,x     ;re invoke mon08

More simple code could work for specific CPU masks
or if your monitor does not need correct PC value
to dipslay after user program returned.

Do you use the write (0x49) or the iwrite (0x19) mon08
command where the cr/lf problem occurs? Can you try to
do a trace with external tools?

Can you start your code by using the run command (0x28)
after read and modify the stack by 0x0c already succesfull
or do you start your code by reset the chip?

There are always 2 echos. First is the HW echo and 
second the mon08 echo. If Baudrate is wrong, even the
first echo can be corrupted if HC08 answers too early
at the halfduplex line. Had a similar problem with 
the 908AZ60 becouse I accidently choosen 2 stop bits.
The HC08 answers pretty fast and the start bit echo
run into the second stop bit what leaded to false
echo interpretation. Thats what I found out with the
external trace what should help to determine the 
reason for your trouble.

For trace I can recommend the listen32 demo from 
http://www.win-tech.com Connect to incoming data
and you will see both directions

> There are always 2 echos. First is the HW echo and 
> second the mon08 echo. If Baudrate is wrong, even the
> first echo can be corrupted if HC08 answers too early
> at the halfduplex line. Had a similar problem with 
> the 908AZ60 becouse I accidently choosen 2 stop bits.
> The HC08 answers pretty fast and the start bit echo
> run into the second stop bit what leaded to false
> echo interpretation. Thats what I found out with the
> external trace what should help to determine the 
> reason for your trouble.
> 
> For trace I can recommend the listen32 demo from 
> http://www.win-tech.com Connect to incoming data
> and you will see both directions

My monitor have very verbose mode ( option -VVVV )
here is the bug:

908JB8:/home/dhp$ write 40 0x0A
Address to be written : 0x0040
Byte to be written : 0xA
Sent 0x49
Received 0x49 after 1ms
Received 0x49 after 0ms
Sent 0x00
Received 0x00 after 1ms
Received 0x00 after 0ms
Sent 0x40
Received 0x40 after 1ms
Received 0x40 after 0ms
Sent 0x0A
Received 0x0A after 1ms
Received 0x02 after 0ms
monitorMC68HC908: when sending a byte, the response byte did not
matched the sen
d byte
received 0x02' instead of `0x0A'.
monitorMC68HC908: Could not perform write
908JB8:/home/dhp$ flush 
Flushing serial buffer
Received 0xF8 after 0ms
Char in the buffer: 0xF8.
Timed out after 100ms
There were 1 cars in the buffer before executing the command

that log says that the monitor send the command 0x49 (write), then the
adress 0x0040 (begin of RAM), then the value 0x0A

but when sending the byte 0x0A, the first echo matches the write, but
not the second echo. That means the software echo do not match the
hardware echo when sending the value 0x0A and 0x0D. I ll test soon all
256 values when I am brave enough to write a script to do so.

At the end, the log says that after receiving the wrong value 0x02,
there is one more char in the receive buffer: 0xF8. As you can see,
many values such as 0x49 are correctly transmitted. My monitor is able
to send runable programs as long as they do not contain one of those
two forbidden values.

I want to add that I have exactly the same bug using two different
boards built from two different schematics.

I get the same error when using iwrite.

On Sat, 31 Jan 2004 21:35:30 +0100, Doublehp wrote:

> I get the same error when using iwrite.

can recommend to use iwrite for speed reasons with download.
Can not see anything wrong in your trace and how you do the thing 
should work. Please check the following:

1)
Never trust your own program at the PC. Trace the outgoing bytes 
with storage scope or other computer with terminal or SW trace
to avoid wrong UART setup and other obstacles

2)
make shure you succesful entered the monitor mode. Can you detect 
the break character for confirmation of entering monitor mode?
I can do so at NT4 and later but for W98 and older systems the
HC08 break character is too short with 11-12 bits to detect by
the PC. Have no experience with the Linux API but the data stream
contains a inserted 0x00 for the case of a break character. This
moment I struggle with FTDI converter cables becouse the insert 
2 characters 0x00 followed by 0xff for such a HC08 break. Another 
bug is, that the HC08 detects a start bit from plug in the cable
and interprets this as the first security byte. Therefore the 
following 7  bytes are shifted and do not open the memory. The 
last security byte send by the PC is then assumed to be the first
mon08 write or read command what leads to false echo.

3)
make shure you do not overwrite the monitor stack. The default reset
value for SP is 0xff and the monitor takes up to a maximum of about
0x10 bytes. This way 0x40 with the start of ram is far away and 
should not make any bugs

4)
make shure the COP watchdog does not trigger while loading data. 
Therefore I always write the CONFIG register first and switch of 
the COP. Be careful, this is a write once register and the application
cannot switch COP on later of there is not reset between. If Vhi
continues at the IRQ pin, the COP should be disabled, but if your HW has
only Vhi at the rising edge of monitor, the monitor continues and will be
interrupted by COP a few msec later what could accidently be the moment
of your 0x0a writes.

> 1)
I have the same error when using iwrite
since I have one char in the buffer after my write, that mean the
serial port receives 3 chars instead of 2 !!!

> 2)
my monitor support such function.

> 3)
I do not overwrite anything: i perform my test just after a reset