Monitoring an 68HC908JB8 under linux
Doublehp
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.
kansas_ray
"Doublehp" <d...@doublehp.org> wrote in message
news:71c62763.04012...@posting.google.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
Android Cat
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.
Doublehp
> 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
>
> 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.
Janvi
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
Doublehp
> 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.
Doublehp
Janvi
> 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.
Doublehp
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
Janvi
>> 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 !!!
I also made false steps with receiving the expected number of characters.
My program is W32 API but maybe your problem is the same. The 16550 UART
has a 16 bit FIFO to avoid the loss of incoming data. In Win32 you can
setup the level on wich the kernal driver receives a interrupt for RX
pending data. That is usually 14 characters and if the kernel driver is
a bit dilly-dally, there are still 2 more characters to buffer in Fifo
until they are lost.
The question is with the mon08 protocol if you only expect 3 characters.
After the incoming 3 characters no interrupt will be generated by the
16C550 UART. Therefore the UART listens to RX line for a time of 3 more
characters. If there is no further data in this time, he will generate
a interrupt to flush its FIFO buffer.
The kernel driver starts service for that interrupt but does not know
how many bytes are pending. Unfortunately in this time further bytes can
be rx - ed (from whatever the reason is like electrical noise spikes or
others). If you know read only the expected bytes by readfile, possibly
some bytes remain in the queue. I do not know the task mechanism in Linux
but windows uses a WaitForObjectEvent to notify the application for
incoming data. If the number of readed bytes and the number of incoming
bytes comes out of sync, you will read a previous pending byte with the
next event. This is specially the case for the break characters what
may insert a unknown number of bytes to the rx - data stream what the
application is responsible to drop.
Maybe the 16C550 problems are exactly same with Linux and I always only
can recommend to use external trace and see what really happens instead
of trusting own SW code.
Hope to hear from your project again
& Good luck
Doublehp
transmitting 2 chars: 0x0A and an other one I forgot (see prevew
posts)
Clifford Heath
ASYNC_LOW_LATENCY setting in the termio ioctls. Linux will delay
interrupting a program doing serial I/O until a certain time
has elapsed or enough characters have arrived to make the context
switch efficient.
I found this when addressing the same problem in my DB11, 68hc11
debugger for *nix - find it on my website as a free source download.
Clifford Heath.
Doublehp
details or a link ?
Clifford Heath
> I did not find ASYNC_LOW_LATENCY in any man page ... can you give more
> details or a link ?
DB11 isn't hard to find. Just google for my name.