Post by thread:16C77 INDF possible bug.

Ray: >We are about to start migrating a 16c74 app to 16c77, and have >been warned of a possible bug in the INDF addressing when >accessing page 3 ram. > >Sorry no additional info at this time, anyone else having >problems with 16C77 and INDF addressing? We used the '77 in a project and actually had a 40 byte buffer locatated on page 3 of RAM, so we made extensive use of indirect addressing on page 3. We never ran into any problems. There are only 2 minor bugaboos, however they are detailed in the data book, so there shouldn't be a problem. They are reiterated below for convenience-sake. 1) The STATUS register contains a bit (called IRP) which sets the indirect addressing to page 0-1 RAM OR page 2-3. It is STATUS,7. When clear (0) it sets the indirect addressing to page 0-1 RAM, while setting it (1) sets the indirect addressing to page 2-3 RAM. A benefit (the drawbacks are obvious) to this scheme is moving data from one buffer to another on another page in RAM can be accomplished elegantly with only a BSF/BCF instruction, assuming the buffers are mapped with due-consideration. 2) The last 16 bytes of RAM on pages 1, 2, and 3 map to page 0 of RAM, regardless of the state of the RPx bits or IRP bit in STATUS. As such there are 48 fewer bytes of user accessible RAM available than would appear by looking at the addressing scheme. A benefit of this (again the drawbacks are self-evident) is declaring "global" variables which can be modified regardless of what page of RAM the program is working with at the time. This is useful for flags and the like. Good luck with your project, David Brobst General Partner, Solutions Cubed

<snip> > >We used the '77 in a project and actually had a 40 byte buffer locatated on >page 3 of RAM, so we made extensive use of indirect addressing on page 3. >We never ran into any problems. There are only 2 minor bugaboos, however >they are detailed in the data book, so there shouldn't be a problem. They >are reiterated below for convenience-sake. > <snip> >David Brobst >General Partner, Solutions Cubed Hi David, Thanks for the confirmation, Some details haven't yet been clarified, but generally the problem manifests itself in the following way. When IRP bit is set for INDF access to page 3 BUT the RP1 bit is set for page0. Everything appears fine UNTIL you perform some operation which updates the status reg. Like something which updates Z. Then everything falls over. The answer (I think) is simply to ensure the RP1 bit and the IRP bit always track each other when using INDF addressing. RP0 is of course irrelevant since the FSR is 8 bits. I should be able to confirm that this was the cause within the next few days. Ray Gardiner (DSP Systems) rayKILLspamdsp-systems.com http://www.dsp-systems.com private email to:- .....rayKILLspam.....netspace.net.au

Ray (and David), thanks for posting this. I'm also moving a project from the 16C74A to the 16C77. My intent was to set IRP and then the RP0/1 bits for a given page. I have'nt got that far yet. Currently I'm busy with moving code to banks 2 and 3 and adjusting registers for the upper 16 Bytes that are aliased between the banks. The first things to go are the registers that are saved in my ISR routine. Since I use all of the bank 0 registers and most of bank 1, I'm tempted to do a complete re-write of the code for the '77... I would like to implement data buffers for a variety of sensor inputs in banks 2 and 3. Currently, my ISR and state machine responds to many events on a per-Byte basis. Please keep us informed. Thanks, - Tom At 03:09 AM 3/6/98 +1000, you wrote: {Quote hidden}><snip> >> >>We used the '77 in a project and actually had a 40 byte buffer locatated on >>page 3 of RAM, so we made extensive use of indirect addressing on page 3. >>We never ran into any problems. There are only 2 minor bugaboos, however >>they are detailed in the data book, so there shouldn't be a problem. They >>are reiterated below for convenience-sake. >> ><snip> >>David Brobst >>General Partner, Solutions Cubed > >Hi David, > >Thanks for the confirmation, Some details haven't yet >been clarified, but generally the problem manifests itself in >the following way. When IRP bit is set for INDF access to page 3 >BUT the RP1 bit is set for page0. Everything appears fine >UNTIL you perform some operation which updates the status reg. >Like something which updates Z. Then everything falls over. > >The answer (I think) is simply to ensure the RP1 bit and >the IRP bit always track each other when using INDF addressing. >RP0 is of course irrelevant since the FSR is 8 bits. > >I should be able to confirm that this was the cause within the >next few days. > > >Ray Gardiner (DSP Systems) EraseMErayspam_OUTTakeThisOuTdsp-systems.com http://www.dsp-systems.com >private email to:- rayspam_OUTnetspace.net.au > >