I have a TableView with some TextFields in. The values of said TextFields are linked to certain positions in a 2D Array (NSArray of NSMutableArrays).

An initial clean array is defined as so:

self.cleanEditContents = @[
                      [@[@-1,@-1] mutableCopy],
                      [@[@0,@80] mutableCopy],
                      [@[@0,@500] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy],
                      [@[@-1,@-1] mutableCopy]
                      ];


This array is supposed to be kept separate from the 'active' array, so that the active array can be reset on a button press.

I use self.editContents = [self.cleanEditContents copy]; to set the active array both directly after the clean array is populated and on a button press.

There is a problem where even though I reset the array and call reloadData and setNeedsLayout (overkill? probably), the numbers don't reset. I tried outputting the values of the same position in both arrays and it turns out that any changes made to the active array contaminate the clean array.


Question: Sending Via PIC18F97J60 EUSART
Answer: One annoying misfeature of the UART on every PIC I've worked with is that a data overrun error will shut down the receiver until code disables and re-enables it.  It is thus imperative to have code that will periodically check the overrun-error flag and, if it is set, disable and re-enable the UART receive function.  Otherwise if the receive buffer overruns, you won't just lose a received byte--you'll lose all data forevermore.

I'm not really sure why Microchip designed their UARTs this way.  My guess would be that in early PICs a receive overrun would cause the receive state machine to lose frame sync, and that disabling the receiver was considered preferable to receiving randomly-framed data (I might agree with them on that point, though I would consider dropping whole bytes while maintaining sync to be better still); later PICs maintained the behavior for compatibility, despite substantial redesigns of the UART subsystem.

In any case, the PIC's UART implementation is what it is.  Check to ensure that the UART receiver is enabled and the receive-overflow isn't tripped.  If not, disable the UART receive function and re-enable it.  Note, btw, that on some PICs the master disable for the UART function will not disable the receiver; you need to clear and re-set the receiver enable.