Hserin Timeout Fail

[Yasin]

Code Select Expand

; Use the Fuse Configurator plug-in to change these settings
Device = 18F87K90
Config_Start
  RETEN = On ;Enabled
  INTOSCSEL = High ;LF-INTOSC in High-power mode during Sleep
  SOSCSEL = High ;High Power SOSC circuit selected
  XINST = On ;Enabled
  FOSC = HS1 ;HS oscillator (Medium power, 4 MHz - 16 MHz)
  PLLCFG = On ;Enabled
  FCMEN = OFF ;Disabled
  IESO = OFF ;Disabled
  PWRTEN = OFF ;Disabled
  BOREN = SBORDIS ;Enabled in hardware, SBOREN disabled
  BORV = 3 ;1.8V
  BORPWR = ZPBORMV ;ZPBORMV instead of BORMV is selected
  WDTEN = On ;WDT controlled by SWDTEN bit setting
  WDTPS = 32768 ;1:32768
  RTCOSC = SOSCREF ;RTCC uses SOSC
  CCP2MX = PORTC ;RC1
  ECCPMX = PORTE ;Enhanced CCP1/3 [P1B/P1C/P3B/P3C] muxed with RE6/RE5/RE4/RE3
  MSSPMSK = MSK7 ;7 Bit address masking mode
  MCLRE = On ;MCLR Enabled, RG5 Disabled
  STVREN = On ;Enabled
  BBSIZ = BB2K ;2K word Boot Block size
  Debug = OFF ;Disabled
  Cp0 = On ;Enabled
  CP1 = On ;Enabled
  CP2 = On ;Enabled
  CP3 = On ;Enabled
  CP4 = On ;Enabled
  CP5 = On ;Enabled
  CP6 = On ;Enabled
  CP7 = On ;Enabled
  CPB = OFF ;Disabled
  CPD = On ;Enabled
  WRT0 = OFF ;Disabled
  WRT1 = OFF ;Disabled
  WRT2 = OFF ;Disabled
  WRT3 = OFF ;Disabled
  WRT4 = OFF ;Disabled
  WRT5 = OFF ;Disabled
  WRT6 = OFF ;Disabled
  WRT7 = OFF ;Disabled
  WRTC = OFF ;Disabled
  WRTB = OFF ;Disabled
  WRTD = OFF ;Disabled
  EBRT0 = OFF ;Disabled
  EBRT1 = OFF ;Disabled
  EBRT2 = OFF ;Disabled
  EBRT3 = OFF ;Disabled
  EBRT4 = OFF ;Disabled
  EBRT5 = OFF ;Disabled
  EBRT6 = OFF ;Disabled
  EBRT7 = OFF ;Disabled
  EBRTB = OFF ;Disabled
Config_End
;**** End of Fuse Configurator Settings ****
;-------------------------------------------------------------------------------
Xtal = 40
Declare All_Digital = TRUE
Declare Hserial_Baud = 9600 ' Set Baud rate to 9600 for HSerin
Declare Hserial_Clear = On ' Clear the buffer before receiving
Dim i As Byte
ANCON2.5 = 0
Symbol  RUN             = PORTH.2
Output PORTH.2

LCDCON.7 = 0
LCDREF.7 = 0
LCDSE0 = 0
LCDSE1 = 0
LCDSE2 = 0
LCDSE3 = 0
LCDSE4 = 0
LCDSE5 = 0
Main1:
    Clrwdt
    Toggle RUN
    HSerIn 1000,Pass1,[i]
    HSerOut [i]
Pass1:
    GoTo Main1
End
The timeout in this code is not working correctly. The value doesn't matter, it takes about 90 seconds.
Best regards.

[Yasin]

The same issue applies to "HRsin"

[Yasin]

Maybe a hardware problem. I compiled the same code for PIC18F8722. No problem.

[Yasin]

As a result of my all-day trials, there was no progress. The MCU with the problem is the PIC18F87K90. I've tested all of the compiler's asynchronous communication methods. The result I found; Unable to set timeout feature in asynchronous serial communication for this MCU. Possibly all the specified timeouts are running as 65535.

Code Select Expand

hserin
hrsin
Rsin
Serin

Parity Error Label

Unfortunately, this tag is not used either.

Best regards.

[top204]

The commands listed use very different assembler code, but they are all suffering from the same issue, which sounds like the microcontroller is not running at the speed that has been told to the compiler in the Xtal declare.

A simple test to see if the microcontroller is running at the Xtal speed is to toggle an LED at a specific speed, and see if the LED is actually toggling at that speed, or slower or faster.

A better method is to create a loop and within the loop add the command HRsoutLn "Hello World". If the text is not displayed correctly on a serial terminal at the Baud specified in the declares, the microcontroller is operating at an incorrect speed.

Make sure the PLL is being implemented in the hardware from a 10MHz crystal to give the 40MHz operation, otherwise, the device is actually running at 10MHz, or slower, but the code is setup for 40MHz, meaning it will run a lot slower.

Remember, the Xtal declare is simply a directive that tells the compiler what calculations to perform for its internal delays, based upon the speed the compiler has been told that the microcontroller is operating at. It does not control the speed of the microcontroller itself.

[Yasin]

Hello Les,
I tested it with Led Blink, it works as expected. I prepared bootloader with UMC_loader. It works normally. Serial communication works as I declared, so Baudrate statements are correct. Crystal 10MHz Checked. The bad thing is that 300 pcb were produced. I was using PIC18F8722 before on this pcb. Since there was a supply shortage, I made minor revisions and used the PIC18F87K90. I have almost no ASM knowledge. The compiler-generated code for both MCUs appears to be the same. The only difference in operation is that no matter what value is assigned, the timeout runs for about 1 minute.

Best regards.

[tumbleweed]

Code Select Expand

Config_Start
XINST = On ;EnabledI doubt that this is supported by the compiler... turn it off

[top204]

Well spotted Tumbleweed.

With that fuse set, the program will go crazy because it actually alters the whole mechanism of the devices.

When testing a device, always examine the config fuses, because some of then do very silly things to the microcontroller's operations. The Xinst fuse alters the mnemonics and RAM of a device, for very little reason. I think it was a hap-hazard way of Microchip trying to make the devices more suitable to stack based compilers, but it fails to do so and actually makes a device less efficient, for the sake of a few extra indirect mnemonic operations.

I moved this thread from the anomalies section of the forum. Please check and double check before issuing an anomaly warning, because it gives the wrong impression to the compiler's users. Please remember.... A fault in a code's operation is not always the compiler's fault. In fact it seldom is, but can be sometimes, so I have to know that a possible anomaly is actually a possible anomaly and not a user code fault, otherwise, I can waste hours trying to replicate an anomaly that is not there. :-)

[Yasin]

Dear @tumbleweed and dear Les thank you very much for your help. I applied the suggestion now, everything is working normally. I've done hundreds of tries, including config adjustments. But I skipped it. I guess I was a little stupid. This was something I would never have thought of. It's actually nice that Microchip is improving their products. Les occasionally criticizes Microchip's changes. I agree with Les on this matter. Bringing such well-established functions to the compiler by maintaining support for older MCUs must be a really tough job. That's why I take my hat off to Les's work. Very valuable for me.

King regards.

[top204]

Glad you got it working Yasin.

The problem with Microchip is that they make so many changes, and most are for no reason whatsoever! Then, a lot of the changes they make seem to be by people who do not actually, physically, use the microcontrollers, and they sometimes make things worse, or more confusing for little reason. :-) As my dad used to say "Just because it looks good on paper does not mean it is good in real life"

The AVR and SAM users are in for big surprises now that Microchip can, and will, mess around with the devices that were standardised over the years by Atmel.