16F1828 SEROUT2 works badly, but works fine on 16F886 on same hardware
Having a mega super strange issue today.
I have two MCUs - 16F1828, 16F886, both using same breadboard, same USB<>TTL adapters, same code (except config of course).
The chip should transfer some data to PC via the serial port.
On 16F886 everything is working fine. However, on 16F1828 things are wild! Totally different bytes are sent and nothing works properly.
I initially thought it was USB<>Serial converter issue, so I tried 3 different ones - CH340, PL2303, FTDI - all work fine with 886 but do not work with 1828.
Here is the simple code:
For X=0 to 255
SEROUT2 portc.5,84,[X]
PAUSE 30
NEXT
On the 886, it generates "normal" output - when saving received hex file and checking it with editor, it is normal file - 00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D etc. are written in it next to each other. However, if I run same code on 1828, the output looks as follows:
Code:
00,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F
00,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F
90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F
90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F
A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF
A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF
And so on. It is weird, but some kind of logic can be seen. I thought that maybe variable storage mismatch or something like that, so tried to send individual bytes, and some thing happens - depending on the value, left "side" of value is always shifted, as can be seen in example above.
As said, tried different USB adapters, tried to change port settings - like inverted, not inverted, port speed, parity, etc. No change. Also tried to adjust series resistor in port - also no help. Connected the scope - traces look great and what is most important, my scope, Hantek DSO2D10, has built-in logic analyzer, so it detects and reads 1828 output properly!
I tried to check config settings for the chip, whenever OSC speeds are correct - everything is fine. I also generated some 1ms wide pulses by using pause statement on 1828, and measured their width with scope - yes, they are correct, OSC settings are correct.
I tried to add DEFINE CHAR_PACING 1000 - no change.
I really have no clue what's going on, spent about 4 hours today debugging all these.
Below is the complete code for both MCU.
Any ideas?
Code:
;----[16F1828 Hardware Configuration]-------------------------------------------
#IF __PROCESSOR__ = "16F1828"
#DEFINE MCU_FOUND 1
#CONFIG
cfg1 = _FOSC_INTOSC ; INTOSC oscillator: I/O function on CLKIN pin
cfg1&= _WDTE_OFF ; WDT disabled
cfg1&= _PWRTE_OFF ; PWRT disabled
cfg1&= _MCLRE_OFF ; MCLR/VPP pin function is digital input
cfg1&= _CP_ON ; Program memory code protection is enabled
cfg1&= _CPD_OFF ; Data memory code protection is enabled
cfg1&= _BOREN_ON ; Brown-out Reset enabled
cfg1&= _CLKOUTEN_OFF ; CLKOUT function is disabled. I/O or oscillator function on the CLKOUT pin
cfg1&= _IESO_ON ; Internal/External Switchover mode is enabled
cfg1&= _FCMEN_ON ; Fail-Safe Clock Monitor is enabled
__CONFIG _CONFIG1, cfg1
cfg2 = _WRT_OFF ; Write protection off
cfg2&= _PLLEN_OFF ; 4x PLL disabled
cfg2&= _STVREN_ON ; Stack Overflow or Underflow will cause a Reset
cfg2&= _BORV_19 ; Brown-out Reset Voltage (Vbor), low trip point selected.
cfg2&= _LVP_OFF ; High-voltage on MCLR/VPP must be used for programming
__CONFIG _CONFIG2, cfg2
#ENDCONFIG
#ENDIF
;----[Verify Configs have been specified for Selected Processor]----------------
; Note: Only include this routine once, after all #CONFIG blocks
#IFNDEF MCU_FOUND
#ERROR "No CONFIGs found for [" + __PROCESSOR__ +"]"
#ENDIF
TRISA=%00000000 'PORTS AS OUTPUTS
TRISB=%00010000
TRISC=%00000110 'TWO AS BUTTON INPUTS
OSCCON=%01110011 'INTOSC ENABLED AT 8MHZ
WPUC=%0 'DISABLE C PULLUPS
WPUA=%0
WPUB=%0
ANSELA=%0 'DISABLE ADC
ANSELB=%0 'DISABLE ADC
ANSELC=%0
ADCON0=%0
OPTION_REG=%11011000 'disable pull-ups
DEFINE OSC 8 'SET OSC 16MHZ
X VAR BYTE
FOR X=0 TO 255
SEROUT2 PORTC.5.84,[X]
PAUSE 30
NEXT
;----[16F886 Hardware Configuration]--------------------------------------------
#CONFIG
cfg1 = _INTRC_OSC_NOCLKOUT ; INTOSCIO oscillator: I/O function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN
cfg1&= _WDT_ON ; WDT enabled
cfg1&= _PWRTE_OFF ; PWRT disabled
cfg1&= _MCLRE_OFF ; RE3/MCLR pin function is digital input, MCLR internally tied to VDD
cfg1&= _CP_OFF ; Program memory code protection is disabled
cfg1&= _CPD_OFF ; Data memory code protection is disabled
cfg1&= _BOR_OFF ; BOR disabled
cfg1&= _IESO_ON ; Internal/External Switchover mode is enabled
cfg1&= _FCMEN_ON ; Fail-Safe Clock Monitor is enabled
cfg1&= _LVP_OFF ; RB3 pin has digital I/O, HV on MCLR must be used for programming
cfg1&= _DEBUG_OFF ; In-Circuit Debugger disabled, RB6/ICSPCLK and RB7/ICSPDAT are general purpose I/O pins
__CONFIG _CONFIG1, cfg1
cfg2 = _BOR40V ; Brown-out Reset set to 4.0V
cfg2&= _WRT_OFF ; Write protection off
__CONFIG _CONFIG2, cfg2
#ENDCONFIG
TRISA=%00000001 'SET A TO OUTPUT 1=input
TRISC=%00000000 'set half C for in/out
TRISB=%00011000 'set PortB to output
ANSELH=%00000000 ' ADC OFF B
ANSEL=%000000000 'configure PortA as digital except first 2
ADCON1=%10000000 'adc justify
OSCCON=%01110101 'SET FREQUENCY TO 8MHZ
WPUB=%00000000 'turn off Pullups
CM1CON0=0 'DISABLE COMPARATORS
CM2CON0=0 'SAME HERE
DEFINE OSC 8
DEFINE ADC_BITS 12
DEFINE ADC_CLOCK 5
DEFINE ADC_SAMPLEUS 5
X VAR BYTE
FOR X=0 TO 255
SEROUT2 PORTC.5.84,[X]
PAUSE 30
NEXT
Re: 16F1828 SEROUT2 works badly, but works fine on 16F886 on same hardware
Here is better explanation - the top row shows how data should look, and bottom row shows what actually is delivered.
It looks like for each 32 bytes, 1st bit has it's value increased by 8.
Very strange.
Code:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
00 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
Re: 16F1828 SEROUT2 works badly, but works fine on 16F886 on same hardware
I did a bruteforce approach - sumbitted variable changing from 1 to 65535 to SEROUT2 mode selection, sent fixed set of bytes and watched serial port for them to appear in proper order. 89 worked well. Strange, why for 886F 84 is fine but here we need 89.
Re: 16F1828 SEROUT2 works badly, but works fine on 16F886 on same hardware
89 was for FTDI chip.
For CH340 it needs 92.
Very strange, why this is happening...
Re: 16F1828 SEROUT2 works badly, but works fine on 16F886 on same hardware
Send a capital 'U' ($55) and measure the bit timing. 9600 baud should be 104us/bit.
