Strange effects when switching from 16F1783 to 16F1786 - Page 2


+ Reply to Thread
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 35
  1. #16
    Prolific Poster pic-ignorant's Avatar
    Join Date
    Oct 2007
    Posts
    2,942
    Thumbs Up
    Received: 25
    Given: 31
    Total Downloaded
    926.61 MB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hi Mischa,
    A shot in the dark... It may be worth trying to remove the Dead Code and Optimiser lines.

    Regards
    John

  2. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  3. #17
    PA1OKZ
    Guest PA1OKZ's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Thanks John, I've already tried that but it doesn't influence the problem at all. Forgot to mention it; if so many things have been tried already you easily forget to mention one :-).

    I have inbetween figured out that the effect depends from the interrupt rate clearly; At low interrupt rate, errors occur more rarely (but still do) while the screen even gets unreadible at a very high interrupt rate. I reach this by changing the start-value of the Timer0 counter to a higher value (variable S_METER), causing overflows with a higher rate of course. Disabling all interrupts solves the problem....

    Theoretically this shouldn't affect the behavior, so it's rather clear to me that I have to focus on an Interrupt issue....

  4. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  5. #18
    PA1OKZ
    Guest PA1OKZ's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    OK, stripped the code further down to get a cleaner image, it looks as follows:

    Code:
    Device 16F1786  
    Reminders off
    Config1 FOSC_HS, WDTE_OFF, PWRTE_ON, MCLRE_OFF, CP_ON, CPD_OFF, BOREN_ON, CLKOUTEN_ON, IESO_OFF, FCMEN_OFF
    Config2 WRT_OFF, VCAPEN_OFF, PLLEN_OFF, STVREN_OFF, BORV_LO, LPBOR_OFF, LVP_OFF
    Reminders On
    Declare Xtal = 16             
    Clear
    All_Digital true
    
    ' Interrupt
    Symbol TMR0IE = INTCON.5       ' Interrupt Enable for TMR0 Overflow
    Symbol TMR0IF = INTCON.2       ' TMR0 Overflow Interrupt Flag
    Symbol GIE    = INTCON.7      
    OPTION_REG = 000001         ' Timer0 prescale = 4; PSA = 0; rising edge increment counter; internal clock 16MHz
     
    ' HD44780
    Declare LCD_ENPin = PORTB.3
    Declare LCD_RSPin = PORTB.2
    TRISB  = 000000   
    ANSELB = 000000
    WPUB =   000000     
    
                 On_Hardware_Interrupt GoTo Isr                 
                 TMR0IE = 1                                         
                 GIE = 1                                                                
                 GoTo LOOP                        
    Isr:
                 Context Save                                                 
                 Toggle PORTC.7
                 TMR0IF = 0                      
                 Context Restore                      
    LOOP:
                 DelayMS 100
                 Print At 1,1,"1234567890"
                 GoTo LOOP
    End
    This is as simple as I can make it. I monitor PortC.7 to see whether interrups occur as expected, which they do, nicely stable. In this simple setup, the display remains screwing up. Only when I bring down the interrupt rate significantly, the problem occurs much less.

    To compare:

    16F1786: Interrupt rate of <250us already causes weird behavior of the CPU
    16F1783: Interrupt rate can be as high as reachable at 16MHz clock, being ~5us, and still the behavior is perfect.

    I've got the feeling something screws up during context saving, or maybe somebody has a more clever thought?

    Best regards,

    Mischa

  6. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  7. #19
    david
    Guest david's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hi Mischa,
    You've got a good one there.

    If you write (once) to the LCD and then go in to the interrupt routine does it still trash the existing display or is it only occuring when writes to the display are being interrupted? It should only be the latter situation.

    If you clocked a 1783 and a 1786 off the same xtal could you use 2 oscilloscope probes (one on each display) to compare the LCD lines to see if the 1786 is latching (incomplete) display data prematurely?

    Cheers,
    David

  8. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  9. #20
    PA1OKZ
    Guest PA1OKZ's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hi David, thanks for your response.

    When I write to the LCD only once (top of the program, outside of the loop), the display still "screws up", the text dissapears instantly, mainly by blanc characters since the received data from around the interrupt routine is invalid.

    There should not be any data on the ports that are connected to the display - especially the EN(able) port should remain low since nothing is written to it. During Interrupt occasions however, there is clearly data on each port that the 16F1786 has (also portA, portC and portE pins). I do trigger the scope at PortC.7 on rising and falling edge, which is the one that I toggle in the ISR and monitor the port pins therefore only during ISR...

    I did exactly the same with the 16F1783, this one is nice and clean - no such issues.

    It sounds strongly like something goes wrong either with bankswitching OR context saving and restoring during the ISR I suppose. From the ASM however, I cannot see anything weird, but my knowledge from this respect is limited. Any suggestions are more then welcome, this one is above my knowledge...

    Mischa
    Last edited by PA1OKZ; 7th November 2013 at 12:19.

  10. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  11. #21
    Fanatical Contributor top204's Avatar
    Join Date
    Feb 2002
    Posts
    3,599
    Thumbs Up
    Received: 341
    Given: 162
    Total Downloaded
    1.99 GB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    The 16F1783 and 16F1786 are almost identical apart from one has more stuff than the other. The RAM banks and code memory margins are exactly the same.

    A simple comparison of the asm produced by compilation of the above program for a 16F1783 and 16F1786 shows no major differences in the main body of the code or the compiler's library routines, other than those that cater for the extra RAM and peripherals. All RAM switching and context saving (what there is of it. i.e. none), and RAM adresses are identical for both devices, therefore, the code is working as expected if it works on the 16F1783. I noticed that the BASIC code is relying on the All_Digital directive to switch everything off. As I've stated in the past, this is not 100% reliable with newer devices because of their complexity, and Microchip hiding important aspects of the device in obscure footnotes of datasheets.

    There are several logical approaches to diagnosing and correcting an anomalous result:

    Read the device's datasheet and make sure there is not an obscure peripheral difference, or extra peripherals that need disabling/enabling.

    Read the device's errata sheet.

    Download the latest MPLAB and read its what's new file for the MpasmWin assembler. If alterations to the device's inc file have been made, the compiler's ppi and def files will need to be altered accordingly. If it was incorrect in the official microchip inc file, it is wrong in the compiler, unless I spotted it myself and corrected it, therefore, it will be in the compiler's what' new file.

    Load the project into MPLAB and make sure the fuse settings are as required. Again, this may be due to an anomalous inc file.

    Make sure your device programmer is actually programming correctly for that device. I know this sound obvious, but you'd be surprised at how common this is as a problem.
    Last edited by top204; 7th November 2013 at 13:02.

  12. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  13. #22
    Prolific Poster hadv215's Avatar
    Join Date
    Sep 2009
    Posts
    1,136
    Thumbs Up
    Received: 66
    Given: 26
    Total Downloaded
    3.61 GB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hi Mischa,

    Reading the response from Les I can confirm his statement about All_digital = True. I had a weird port problem with a 16F688 and rewrote the whole program in assembler.
    Then turned back to the basic version to come to the conclusion that it did work if I did all the SFR's by hand.
    I can't guarantee this solution will work for you, since the 16F1783 was working OK, but it's worth a try.

    Regards,
    Harm

  14. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  15. #23
    Fanatical Contributor fanie's Avatar
    Join Date
    Oct 2005
    Posts
    7,989
    Thumbs Up
    Received: 31
    Given: 15
    Total Downloaded
    434.52 MB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hello PA,

    I see you use A/D inputs. Some pic's doesn't like it if the input voltage exceeds the supply voltage. I do not know the specific pics, but if an over voltage on an A/D occurs, even momentary it may well jam a few things up while peripherals still run like timers and interrupts.

    It could be possible to simulate analog values while making sure the hardware is subject to low inputs just for testing.

    Similar, make sure you don't have the wrong pins floating where external signals can cause a problem. I always define each port and pins, the unused ones I make outputs.

    I just bet it's going to be something ridiculously stupid causing the problem. Usually is.
    Fanie

  16. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  17. #24
    Fanatical Contributor top204's Avatar
    Join Date
    Feb 2002
    Posts
    3,599
    Thumbs Up
    Received: 341
    Given: 162
    Total Downloaded
    1.99 GB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    The All_Digital directive should be considered as End Of Life. It will switch off the obvious peripherals on most devices, but it is too logistically demanding to maintain for all devices.

    A note will be placed in the manual concerning this, as well as a reminder in the compiler when the All_Digital directive is used.

  18. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  19. #25
    PA1OKZ
    Guest PA1OKZ's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Ok, long story short:

    The All_Digital directive has been in by habit, subsequently I have TRIS, ANSEL and WPU in the code as well. I have left out INLVL, ODCON and SLRCON here since earlier attempts learned that adressing them doesn't make any practical difference. It this the way to proceed (as in should I address more SFR's to "replace" the All_Digital directive)? I couldn't find in the manual which SFR's are addressed with the All_Digital command; it might be helpful to list this to get a more clear understanding of it (and the need to add extra SFR's on top of them).
    I've followed Les's advices and came across the Errata sheet. It appears that the silicon revision C0 (which I have) has the following possible issue, that is addressed below:

    4. Module: CPU

    4.1 BRA/BRW
    If a BRA or BRW instruction is executed concurrently with an interrupt event, the ISR routine can restore the PC to an incorrect value.

    Work around
    Use the GOTO instruction rather than the BRA or BRW instruction.

    This happens in (I think) a lot of code as it does in my little testcode in the normal program loop:

    Code:
    LOOP
    F1_000039 equ $ ; IN [TEST.BAS] DELAYMS 100
        movlw 100
        movlp ((__DELAY_MS_) >> 8)
        call __DELAY_MS_
    F1_000040 equ $ ; IN [TEST.BAS] PRINT AT 1,1, "1234567890"
        movlw 128
        movwf BPFH
        movlp (([email protected]) >> 8)
        call [email protected]
        movlw ((((_STRLB__1) + 0X8000) >> 8) & 255)
        movwf FSR1LH
        movlw (((_STRLB__1) + 0X8000) & 255)
        movwf FSR1L
    _PBLB__2
        moviw INDF1++
        btfsc STATUS,Z
        bra _PBLB__3           
        movlp ((PRINT) >> 8)
        call PRINT
        bra _PBLB__2
    _PBLB__3
    F1_000041 equ $ ; IN [TEST.BAS] GOTO LOOP
        [email protected] LOOP
    F1_000042 equ $ ; IN [TEST.BAS] END
    _PBLB__4
        bra _PBLB__4
    F1_EOF equ $ ; TEST.BAS
    _PBLB__5
        bra _PBLB__5
    _STRLB__1
        dt 49,50,51
        dt 52,53,54
        dt 55,56,57
        dt 48,0
    __EOF
    Les, could you advice whether this indeed or not would affect the behavior in this matter and how a workaround could look?
    Last edited by PA1OKZ; 10th November 2013 at 11:02.

  20. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  21. #26
    Fanatical Contributor top204's Avatar
    Join Date
    Feb 2002
    Posts
    3,599
    Thumbs Up
    Received: 341
    Given: 162
    Total Downloaded
    1.99 GB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    The Bra and, to a lesser extent, the Brw mnemonics are an inherent part of the compiler's code. Indeed, they are an inherent part of all code for all compilers for an enhanced 14-bit core device and an 18F device.

    If these very important mnemonics are potentially broken with that particular silicon build, I would consider the device broken, therefore it is useless and another chip is required, or the same one, but a later build. A workaround such as the one mentioned can only be carried out if coding in assembler. The compiler would need to change the whole way it generates code to workaround a broken chip. Needless to say, this isn't going to happen.

    If this is a problem with all, so called, enhanced 14-bit core devices (which is doubtful), that is another reason to switch to 18F types or PIC24 types. I say doubtful, because this issue is not flooding the forums on microcontroller sites and compiler sites, which also use Bra and Brw. So it must only be certain silicon revisions. This is one of the reasons why I don't use newly released devices in a commercial product.
    Last edited by top204; 10th November 2013 at 12:35.

  22. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  23. #27
    PA1OKZ
    Guest PA1OKZ's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hmm, I feared an answer like that. I suppose this makes 16F1784/6/7/8 all useless in combination with Proton, since they all suffer from the same issue in the C0 revision....

    It would be easy to switch to an 18F indeed, but I am missing the exactly same features. Will have a closer look at comparable ones (especially ADC) later on...

    Thank you Les,

    Mischa

  24. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  25. #28
    Fanatical Contributor top204's Avatar
    Join Date
    Feb 2002
    Posts
    3,599
    Thumbs Up
    Received: 341
    Given: 162
    Total Downloaded
    1.99 GB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    I suppose this makes 16F1784/6/7/8 all useless in combination with Proton
    Not just useless with Proton, but useless with all compilers.

    The Bra mnemonic is not just another version of Goto, otherwise, it wouldn't be a separate mnemonic. The Bra mnemonic performs a relative jump that can straddle code page boundaries without needing to manipulate the code page boundary SFR. It also takes less cycles to operate, therefore, any compiler worth its salt will sprinkle the Bra mnemonic liberally wherever it can because it saves time and code space, which was its sole purpose. This anomaly will also affect the Bz, Bnz, Bc, Bnc mnemonics, and more, which are at the very core of any compiler.

    The Brw mnemonic cannot be replaced by a Goto mnemonic because it is a relative jump based upon the contents of WREG. It would need to be replaced by several mnemonics.

    Bottom line is that Microchip have dropped a clanger with these devices (not the first time, and certainly not the last time), and I stick to my statement that these revisions are broken and next to useless.
    Last edited by top204; 11th November 2013 at 22:34.

  26. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  27. #29
    PA1OKZ
    Guest PA1OKZ's Avatar

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Yes, I should have been a little more precize; it wasn't addressed neither limited towards Proton - exactly the opposite truly, meaniong Microchip.

    Might be useless, but I have opened a ticket at Microchip to learn if the first revision is widely spread or not, and how to achieve some samples of the latest ones. Interestingly enough, the revision C1 (in which it's fixed) has been introduced straight after initial product release. Let's see if (and what) this brings....

  28. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  29. #30
    Member kuhrig's Avatar
    Join Date
    Aug 2005
    Posts
    108
    Thumbs Up
    Received: 4
    Given: 0
    Total Downloaded
    4.71 GB

    0 Not allowed!

    Default Re: Strange effects when switching from 16F1783 to 16F1786

    Hi Mischa,

    after I read your thread I am really scared to use the PIC16F1789 in one of our project. It has nice features I would like to use... and cheap.
    How can you ensure to get the correct revision, specially when you produce in Asia? Difficult.

    After Les comments I have to switch to 18F devices. Unfortunately only a 18F TQFP64 package offers the same ADC ports as the TQFP44 package of the PIC16F1789.

    Thanks for starting this thread. Will save me lot's of time and costs.

    Rgds
    Kai

  30. Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

     

Similar Threads

  1. 16F1786/88 ADC Reading Issue
    By P.N. Shaji in forum Proton Plus Compiler v3
    Replies: 5
    Last Post: 10th July 2015, 21:13
  2. 16F1783 and Pickit2.......
    By robbed666 in forum Proton Plus Compiler v3
    Replies: 1
    Last Post: 1st July 2013, 11:26

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts