![teraterm xmodem teraterm xmodem](https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/TeraTerm4.jpg)
So replacing it shouldn't be the cause of any problems. I think that variable is doing exactly what the comment says, because gl.recv_ptr is the memebr of a struct I imagine the access code that was being generated by IAR (back in the version that was contemporaneous with when AVR350 was written) presumably generated "heavy" access code so this was just a case of "hand optimization" on the authors part to get it into a 16 bit register and keep it there throughout the function. (though if you ping me again on Monday I'll have a quick look at that - I don't have access to my xmodem code here at home) Now I could try comparing my current xmodem code to the app note code but it's heavily integrated within a whole lot of other stuff that's going on that I think it would be tricky to spot the bug fixes that way too.
TERATERM XMODEM SOFTWARE
I think I've seen links on here to free UART protocol analysing software that offers the same facilities and a tool like that is invaluable for working out what's wrong (a decent logic analyser might also work). The tool I use was FTE s AsyncSerial Test which is "listener" you can put in the conversation between the PC and the AVR and watch all the traffic to see what is/isn't working.
![teraterm xmodem teraterm xmodem](https://support.redlion.net/hc/article_attachments/360045099811/mceclip9.png)
Like I say, if I didn't even remember what the problems were back in September 2006 there's even less hope of me remembering in November 2007 ! Sadly I didn't keep a documented record of what I changed to fix any problems I found at the time (my only goal was to make it work).