Bootload - XOFF not working

[russk2txb]

Hi again. Ok I have the boot loader compiled and it gets invoked, but SIOW is not stopping when the loader sends XOFF. I am using compiler version 5.064. In SIOW, in configuration / Port Options I have set software flow control to both, and the Xon and Xoff values are correct (0x11 and 0x13). Hardware flow control is off, parity none, bits 8, and stop 1. Baud 9600.

In device manager I set the TX buffer size to 64 bytes (and rebooted the computer as instructed - even though I have no idea why that should be necessary for just changing buffer size).

I looked at the data stream with a port monitor but SIOW sends so many IOCTL codes that it overwhelms the monitor even when filtering them out, eventually the monitor crashes with 'out of memory'. But when I stop the monitor after a short while and look at the capture I never see the XOFF and it does not stop after the first line is sent, as it should.

I set a breakpoint in the loader after the line read (and after the XOFF is sent), and it breaks but SIOW keeps on sending for about a hundred lines. This happens even when the loader is not interrupted. When SIOW does stop sending, it pauses for maybe 5 seconds and then starts up again with another hundred or so lines. This happens even when the loader is stopped!

There are other strange observations, like the sent data is corrupted by about the fourth line sent...

Does anyone with experience with SIOW have any idea what is causing this? Oh yes, running Windows 7 Pro.

Thanks, Russ

[dyeatman]

I have the same problem with SIOW crashing as well.
_________________
Google and Forum Search are some of your best tools!!!!

[Ttelmah]

It depends on your UART. In some, the SIOW setting gets ignored, and you have to set flow control in device manager. Also turn the buffer size _down_ in device manager.

This has been mentioned here before, and nobody really knows 'why', but it seems that some devices only listen to their own internal settings, and ignore the commands that are meant to enable flow control from the outside...

So, device manager, flow control Xon/Xoff, and the same in SIOW.

Then in Advanced settings, either turn off 'Use FIFO buffers', or turn them right to the minimum. You will see the comment on these 'select lower settings to correct connection problems'. Large buffers, can give greater speed, but mean that there can be a lot of data sent _after_ XOFF is received (again depends on how the actual driver behaves).

[russk2txb]

Thanks Ttelmah. I think XOFF is working after all. The display in SIOW is very deceptive. When you have local echo turned on it loads up about a hundred lines and then stops and sends them. When I finally figured out how to turn on the options to show CR/LF and extended ASCII characters I could then see what was going on. So I think the load is ok but the app won't run and that is where I left it last night. Now I will see if I can figure that out.

Thanks again, Russ

[temtronic]

Simple solution....get an 'old' PC with Win98 on it ! Really, everything newer has too many 'layers' of smoke and mirrors between the 'RS232' port and the 'terminal program'. I have to assume you've got some USB <>serial device as well...sigh...MORE unnecessary hardware, firmware,etc.
98 was the last version of windows that allowed DIRECT control of the PC UARTS, after that it got 'complicated', now it's............???
One possible 'trick' you can use is to go slow. Reduce baudrate to say 1200 or even 300. That give YOU some time to see the data flow, character by character. Once things seem OK, then bump up to 9600.
Also be very ,very careful about 'upgrades' especially the 'hidden' ones ! Something(still don't know) CHANGED the power limit of one of my USB ports between 'device was working' and 'now it's not'. Power limit had been 500ma now 100ma ! The device(PIC and stuff) needs 250ma....
4 hrs of my life gone for good because 'something' changed MY settings.

Jay

[russk2txb]

Hi Jay and thanks for the advice. Unfortunately that is not going to work (using an old PC). The oldest one I have here is Windows XP, and the serial port on that died years ago so it also uses a USB to serial converter.

But more important is the fact that this bootloader has to work for anyone who needs an update to my firmware. The average user is going to be running at least Win7 if not Win10 these days. So this has to work. Once I get it working with SIOW then I intend to add the code to send the hex file right from the application that already interfaces with the controller board. Maybe that will actually be easier, but I don't want to try it until I am sure the loader itself works and my program will run.

Thanks again, Russ

[russk2txb]

Well I could not really figure out if SIOW was working or not and it was too hard to troubleshoot so I bit the bullet and wrote my own send routines to send the hex file. Now I have control of both ends and it is a little easier to work on. I can send the whole hex file and I get an ACK for every line, but the program will not run. I can run the loader in the debugger and break after it has received a line, and is ready to write the data to program memory. I can see the address of the first write (0x500 as expected), and the data is correct. But when the write_program_memory function is called, nothing is written.

I am basing that on the fact that I can see address x500 in the ROM window of the debugger. It has a branch to its own address there as expected. When I write to that address the ROM values shown do not change. Just to be sure I changed the address to x400 (where there is all zeroes) and still nothing was changed. I am wondering if maybe the ROM window does not get updated when it is changed. If that is the case then I can't figure out a way to tell.

Also, that write call screws up the debugger so that on the next function call it goes off somewhere and never comes back (if single stepping). If I don't set the breakpoint then the program appears to continue running and receives all the lines - but the debugger will not break if the breakpoint is placed after that first program memory write. So I can't really tell if it ever does the processor reset at the end. But the program does not work, and I think it is because nothing was written.

Does anyone have any suggestions? This is a PIC18F4680.

Thanks, Russ