+ Reply to Thread
Results 1 to 18 of 18
  1. #1
    Join Date
    Sep 2017
    Posts
    27

    Default Glitches when changing portD seen on other ports

    Hello
    I am using portD as a data port, 4 bits of portA as an address bus, and porte as the chip select, data strobe and direction bits. When the data switch from 3F to 40, 7F to 80, and BF to C0 there is a glitch. The data bus shows a few values before settling, but what is odd is the address bus, which isn't being changed or written to in any way also sees a glitch then settles back to the address it should have and likewise I get a 4ns pulse on the Chip Select and Data Strobe bits.

    #Config
    CONFIG OSC = HS ;Sets for external oscillator HS = external oscillator high speed Internal = IRCIO67
    #endconfig


    DEFINE OSC 20 'Sets Osc to 20MHZ

    'Setup
    ADCON0 = $00 'Disables A/D module
    ADCON1 = $0F 'Sets inputs to digital
    CMCON = $07 'Takes pins D<3:0> to digital from default PW mode
    CCP1CON = $00
    ECCP1CON = $00
    INTCON = %00111111

    define HSER_BAUD 38400
    DEFINE NO_CLRWDT 1

    Do until x = Length
    'Set data bus
    LATD = X
    'Set the direction
    PORTE.2 = 0
    'Select the chip
    PORTE.0 = 0
    'Strobe the data
    PORTE.1 = 0
    'Disable strobe 'At 8mhz this is active for 1uS at 20mhz this is active for 400nS
    PORTE.1 = 1
    PORTE.0 = 1
    PORTE.2 = 1
    x = x + 1
    loop




    Attachment 8932
    Last edited by svjohngalt; - 29th June 2019 at 04:33.

  • #2
    Join Date
    May 2013
    Location
    australia
    Posts
    1,730

    Default Re: Glitches when changing portD seen on other ports

    no schematic , no descripion of what portd is driving or how its configured
    no description of which 4 bits are in use , so this is just a wild guess


    'Set the direction
    PORTE.2 = 0
    so the unnamed device is an input ?




    PORTE.2 = 1
    so the unnamed device is an output ?




    yet portd is still set as ? sure way to get a glitch






    yet more proof that snippets are a waste of time
    This is more entertaining than Free to Air TV

  • #3
    Join Date
    Jan 2006
    Location
    Istanbul
    Posts
    1,236

    Default Re: Glitches when changing portD seen on other ports

    It seems to be a power supply issue to me.
    Try the following circuit.

    And make sure, other than the 100nf caps below, you have your additional 100nf caps as close as possible to PIC Vss and Vdd pins.

    And one other suggestion: You should not connect the PIC pins directly to an interface; have 100R resistors on each pin you are using.
    Last edited by sayzer; - 29th June 2019 at 08:34.
    "If the Earth were a single state, Istanbul would be its capital." Napoleon Bonaparte

  • #4
    Join Date
    Apr 2014
    Location
    Northeast
    Posts
    314

    Default Re: Glitches when changing portD seen on other ports

    You wrote to LATD but are writing to PORTE. Write to the LAT and read from the PORT. Writing to the PORT involves a READ - MODIFY - WRITE sequence that might be exacerbating your power supply issues (assuming that is an issue).
    I don't need the world to know my name, but I want to live a life so all my great-grandchildren proudly remember me.

  • #5
    Join Date
    Sep 2017
    Posts
    27

    Default Re: Glitches when changing portD seen on other ports

    At the moment I am using the Microchip Explorer 8 board which is how I typically start with a project. All the pins are only connected to the logic analyzer so they are all high impedance.

    Within the loop I am transmitting 255 bytes, for testing they simply increment 00 to FF, increment by 1 with each byte. What I see is that if I do not use portD as a parallel slave port, then the portd is generally stable except at those specific three points when we are switching from the counts noted above to 00. When these three points are encountered, it seems to cause an issue with the RA0..RA3 address bits, and the other RE0..RE2 bits. This could indeed be a power glitch issue. I will be adding caps to to my explorer board and retesting. What I don't clearly understand is why when I set portD to a slave parallel port, the RA0..RA3 bits that I am using for the address is very stable. I've attached a capture in the parallel slave mode. It may be that in parallel slave mode, how portD is clocked is different and this seems to result in a smoother operation. Maybe going from BF to C0 just simply causes a large power draw.

    I do appreciate the input. I have never used a 100 ohm resistor to isolate the output pins between the PIC and any other device. I think I should specify that I am powering the Explorer8 board from the USB port. The power supply filtering only comes into play when using an external power supply so that will also need to be an experiment.

    ThanksAttachment 8934

  • #6
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,541

    Default Re: Glitches when changing portD seen on other ports

    THE well known issue !

    instead of PORTx.y = 1, just place LATx.y = 1 ... and for 0, LATx.y = 0 ...

    this avoids "too fast" writing bits with " PORT ..."

    Alain

    Edit : +1 for MpgMike ...
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  • #7
    Join Date
    Sep 2017
    Posts
    27

    Default Re: Glitches when changing portD seen on other ports

    This glitch does only occur at certain changes when the databus goes from a byte XF to X0. I did power my Explorer 8 board with an external power supply which also includes power filtering. I added a .15uF and 10uF cap for decoupling on the PIC. These really didn't help any. What I did for testing purposes, is to simply prevent it going from F to 0. If the lower nibble is F then I first place XA on the databus, then XF and problem solved. I did try the LATx.y which didn't seem to make a difference, but I will be using LATx.y for output and portx.y for read. Outside of that my project with creating an ARCNET device is progressing. I suspect the root cause is power supply issues. When I layout the board, I will need to make sure the power and ground runs for the PIC are large and provide good bypass capacitors.

    thanks

  • #8
    Join Date
    May 2013
    Location
    australia
    Posts
    1,730

    Default Re: Glitches when changing portD seen on other ports

    if you are using code anything like what you have posted , code that causes bus write conflicts
    why do think that it won't cause glitches, no amount of ps filtering will solve that problem
    This is more entertaining than Free to Air TV

  • #9

    Default Re: Glitches when changing portD seen on other ports

    As Richard posted, your code has potential dangers (RMW) so as advised use LAT rather than Port and
    PORTE.1 = 1
    PORTE.0 = 1
    PORTE.2 = 1
    much better
    LATE = 7 ie binary 00000111
    George

  • #10
    Join Date
    Sep 2017
    Posts
    27

    Default Re: Glitches when changing portD seen on other ports

    I did change the code for all outputs to use LATx.y instead of PORTx.y. I am using PORTx.y for all reads. I didn't re-post the code, but I did indeed take the suggestion. I agree that no amount of power supply filtering would resolve issues that may be caused by code and I am not sure if there is still something yet unknown, but I do think that since it only occurs when switching from XF to X0 it appears to be more related to power. Also, that I can eliminate the glitches totally by just simply outputting LATD = BF, LATD = BA, LATD = C0 instead of LATD = BF, LATD = C0. It would seem to me, and again there may be things which I do not understand, that if it was purely a code execution issue, the glitch would be seen when I make the change from BA to C0. It is also odd that it shows up for only a few nanoseconds, which I think is much slower than the code execution at 20Mhz and seem more like the switching time of gates. I probably need to just test with using different ports and see if it just related to portD.

    thanks
    George

  • #11
    Join Date
    Sep 2009
    Posts
    776

    Default Re: Glitches when changing portD seen on other ports

    I don't know if your PIC have slewrate control. Try to set it to slower speed if you can. As fast rising edge can cause problem due to capacitive coupling to other pin.
    So when you change state on one or more pin, it can pull another line to 0 that is close routed to pins that change states(bad PCB layout). As you see on analyser. Also this could be due to pore probing, as you mention that there is no load at any of pins.

  • #12
    Join Date
    May 2013
    Location
    australia
    Posts
    1,730

    Default Re: Glitches when changing portD seen on other ports

    its difficult to give any sensible advice with such scant details ,not knowing what you are trying to talk to on the data bus
    what actual speed you are operating at or even the code you are trying.

    this worries me , you realise of course that all other config settings revert to chip defaults not pbp defaults
    #Config
    CONFIG OSC = HS ;Sets for external oscillator HS = external oscillator high speed Internal = IRCIO67
    #endconfig
    this worries me , it looks like a slightly wrong attempt to use int osc @500khz , so the actual osc speed is uncertain to me
    INTCON = %00111111

    i'm assuming that device x on the bus is some sort of arcnet network interface , it may assert a busy, data available or idle signal
    at some stages , causing the glitches to appear as they do.

    i would try something like these , but you need to read data sheet re timing and busy signals etc



    trisd=$ff
    Do until x = Length
    'Set data bus
    LATD = X
    'Set the direction
    lateE.2 = 0
    'Select the chip
    latE.0 = 0
    trisd=0
    @ nop ;let bus settle
    'Strobe the data
    latE.1 = 0
    'Disable strobe 'At 8mhz this is active for 1uS at 20mhz this is active for 400nS
    @ nop ;if needed
    latE.1 = 1
    trisd=$ff
    latE.0 = 1
    late=7 ;if needed
    x = x + 1
    loop




    or this




    Do until x = Length
    'Set data bus
    LATD = X
    'Set the direction
    lateE.2 = 0
    @ nop ; read data sheet about timing
    'Select the chip
    latE.0 = 0


    'Strobe the data
    latE.1 = 0
    'Disable strobe 'At 8mhz this is active for 1uS at 20mhz this is active for 400nS
    @ nop ;if needed
    latE.1 = 1
    latE.0 = 1
    late=7 ;if needed
    x = x + 1
    loop
    This is more entertaining than Free to Air TV

  • #13

    Default Re: Glitches when changing portD seen on other ports

    In George's other thread he talks about using an 18F4680 with an ARCNET COM20020i on the bus.

    Have you followed the directions for setting up the bus interface type (80xx/68xx, mux/non-mux) in the COM20020i datasheet?

    More complete details on the code and interconnects might help instead of us guessing.

  • #14
    Join Date
    Sep 2017
    Posts
    27

    Default Re: Glitches when changing portD seen on other ports

    I wanted to update this thread. The glitches refered to are due to the changing of portD from input to output and vice versa. When using x=portD or LATD=x the port is automatically switched between input and output, but that creates issues. My solution was to directly control the port direction by using a TRISD statement before and after the actual x=portD or LATD=x statements and this resolved issues I had. There were some other oddities on how to read and write data to the ARCNET controller which didn't seem to be documented correctly, but I was able to resolve those also.

  • #15
    Join Date
    May 2013
    Location
    australia
    Posts
    1,730

    Default Re: Glitches when changing portD seen on other ports

    When using x=portD or LATD=x the port is automatically switched between input and output
    so how does that work ?

    This is more entertaining than Free to Air TV

  • #16
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    635

    Default Re: Glitches when changing portD seen on other ports

    I had a similar problem before. See the thread below,

    http://www.picbasic.co.uk/forum/show...029#post140029
    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  • #17
    Join Date
    Feb 2013
    Posts
    546

    Default Re: Glitches when changing portD seen on other ports

    I guess there's some "in chip" leaks. I had almost similar issue - say audio amplifier is connected to PORTB.1 via 0.1uf capacitor. And we write a software which outputs 1khz sound on PORD.2, and that pin is in the air, not connected to any load or ground or vdd. So when you launch it, you will hear that 1khz sound thru the amplifier which is connected to PORTB.1, but you should not.

  • #18
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    2,915

    Default Re: Glitches when changing portD seen on other ports

    If it is a low level, it makes sense. Especially if there is no ground around the port lines.

    But if it is more, then maybe some settings are wrong.

    In any case, having a 0-5 volt square signal near a low level audio line is not very good idea.

    Ioannis

  • Similar Threads

    1. 18F45K40 Can't set PORTD.1
      By sayzer in forum mel PIC BASIC Pro
      Replies: 17
      Last Post: - 25th June 2019, 10:23
    2. Replies: 0
      Last Post: - 17th April 2019, 21:01
    3. quick changing of ports for I/O use
      By longpole001 in forum mel PIC BASIC Pro
      Replies: 2
      Last Post: - 30th May 2015, 21:34
    4. LCD display glitches with interrupt
      By Art in forum General
      Replies: 7
      Last Post: - 20th March 2012, 23:18
    5. PortD mistery
      By vizualizer in forum mel PIC BASIC Pro
      Replies: 3
      Last Post: - 30th March 2009, 13:40

    Members who have read this thread : 23

    You do not have permission to view the list of names.

    Posting Permissions

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