Monitoring an 68HC908JB8 under linux

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

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.

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

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(fddevice); 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

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

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.

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.

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 !!!

my monitor support such function.

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

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

I am not sure my problem is so complex: I have a bug only when transmitting 2 chars: 0x0A and an other one I forgot (see prevew posts)

Without heaving read all of this thread, you should look at the 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.

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.