Hot!18F27/47K42 wrong generated = PROBLEM SOLVED :)

Author
karadev
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2012/07/20 02:23:59
  • Location: 0
  • Status: offline
2018/08/09 13:28:26 (permalink)
0

18F27/47K42 wrong generated = PROBLEM SOLVED :)

18F27/47K42 wrong generated signals on same port B
hello colleagues, I would like to congratulate you on the outstanding work on making the processor on my assignment - 18F47k42-8192 SRAM. the processor is extremely good as the rest of the same family. we already have several units and tested the new 40-pin version.

my fellow programmers are impressed with your work. we also installed MPLAB-5.00 and xc8-2.00. we also used the configurator code to activate the peripheral modules of the CPU, because as we have learned, the old PLIBs are no longer working.

the processor is tested on a high-frequency circuit and software that allows you to see the port logic analyzer's work.

here's what I can show you. I'm sending you some logical analyzer charts, to which I clearly highlighted red and green where the problem is and how we solved it.

I will give some clarification. we've set PORT B to work in a certain way by generating signals with a maximum CPU frequency of 64MHZ. quartz resonator is 16 + PLL = 64Mhz. gate is set only on digital outputs, there is no peripheral to this port, just digital outputs with frequency. as a basic configuration, the CPU is only set to work with an external generator without any additional extras from the fuses. all outputs are digital on all ports, there are no other peripheral devices, built-in protocols, or other hardware extras.

as is clear from the first graph with the wrong signal from output RB5, the generated signal has missed impulses in the generation. the signal is also inverted as a constant logic 1, and the gate is reset in 0 shortly after command by the processor. this is a wrong signal generated by both pulse count and 0/1. the graph shows that the signal has gaps in the generated impulses and quite a lot. also the signal is inverted, being in constant 1, and the pulse resets in 0 it briefly and then again makes it in logic 1.

on the following graph I have shown how the generated signal should look like, but this output has been replaced with the output of port RC0. I decided to try to move the exit to see if there was any improvement. it turned out that the generated signal from port C is correct and the controller correctly manages the external peripheral equipment connected to it.

as shown in the generator signal graph, the generated signal has a full number of impulses during operation and is no longer inverted. from normal zero 0 is briefly in logic 1 and then returns to zero 0 as it is written in the processor code.

just to tell you that in the previous version of the controller we used the 18F46K20 processor. there is the same problem, so the front gate gate has been shifted to RC2 as in this variant.

the circuit has two control ports, and because the signals from the different frequency generations have been collapsed, we have separated the separate ports to send separate signals to the managed equipment.

on the project we are working on in the previous version with 46k20 and in this version with 47k42 are enough to implement the scheme 28 pins processors with generation of signals from one port. but after we noticed that there was a brawl of signals during a generation at the gate, we decided to split the ports into two separate ones, and that's why we use 40 pin processors.

as shown by your processors, the ones I have used so far have not had any serious low frequency problems. e.g., 4,8,16MHz. but now at 64MHz there is a problem that will have to be investigated by you and removed.

I know that in any processor, as it is said at any time and on each PORT and pin, any output digital signal can be generated independently of the outputs generated on the other outputs of the same port.

so on the same port, any pin can generate a digital output signal without disturbing the digital signal of the neighboring pin of the same port. or as it is right for each pins to know the signal without interfering with the next pin beside it.

I suppose the problem may be in the electronic module on the final stage of a port and / or all ports. may be in the PLL module and only occur at high frequencies. it may only appear when the software is set to have digital outputs and / or in combination with a high frequency from the gatherer. many options are possible. e.g., a specified command in the microcode that fails to execute, and / or any one of the logic that responds to this command at a high frequency fails to execute the command. or not, and reaches the reaction time, and for that, it misses the impulses, and then begins generating again.

=========================================================

I'm sure you will find the problem, as I said, the 47k42 processor is extremely good and will serve us for many things in electronics.

before making this 47k42-8192 SRAM model as well as the whole family, we used 4620 and 46k20 at low frequencies up to 16 MHz there were no problems, everything worked. I am very pleased with both. now we have a problem with this problem with the ports, but we have found a solution. it costs us almost nothing, only a few samples of different variants. there is not much difference in the price of the 28-pin and 40-pin processor, as well as in the software and PCB modification. but I'm glad if I'm right and I've found a problem that you're going to handle. I am sure.

the new processor with the increased memory frame 8192 has greatly helped our electronics. as I wrote you in the previous letter, I expect you to increase the memory of the other 18F, 18F ___ K ___, 18F__J__ families. especially those processors that have a 28,40,64,80 and 100 pin housing. for example, I will give the 18F87K22 processor, which is very powerful and good, but this little memory frame can not be fully used.

I will give only one example. there are processors that have an example 64 pin housing. there are many ADC ports, serial ports, many peripherals, and RAM memory only 4096 or even less. the processors are 16 MIPS, extremely fast, powerful and rich in peripherals, and with this little memory frame 4096 or 3886 you are crippling them. Nowadays, there are good graphical displays made with enough large size touch screen screens, there are pretty good and accurate sensors of any kind for analog and digital measurement of dimensions, there are all communication modules for wired and wireless communication. but with 4096 and / or fewer memory frames, we can not trigger these mods even when the processor is 64 or 80 pin.

I need my RAM memory and I think 8192k is just as much for this architecture of all the 18F_______ families

for now is this, I want to tell you once again that you are super as a company to thank you for listening to me to increase the memory of this processor and I'm sure you will find a solution to the problem.

if I need to send you the code of the function that activates this error, as well as the CPU configuration files.

also if you need some other information from us on this issue you can rely on us.

best regards - Kaloyan Radev and my team of programmers :)
 
P.S. in red picture corect port is PORT B, my mistake in photoshop text typing :)
post edited by karadev - 2018/08/14 12:26:48

Attached Image(s)

#1

10 Replies Related Threads

    MBedder
    Circuit breaker
    • Total Posts : 6467
    • Reward points : 0
    • Joined: 2008/05/30 11:24:01
    • Location: Zelenograd, Russia
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/09 13:46:18 (permalink)
    +1 (1)
    1) Check and fix line #47 in your code.
    2) For such a global problem your description is too short, add 27+ pages to clarify.
    #2
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/09 14:25:15 (permalink)
    0
    grin
    I was going to say the same...

    GENOVA :D :D ! GODO
    #3
    jtemples
    Super Member
    • Total Posts : 10943
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/09 15:17:22 (permalink)
    +1 (1)
    I'm guessing you're writing to PORTB instead of LATB.
    #4
    qɥb
    Monolothic Member
    • Total Posts : 3329
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/09 15:47:36 (permalink)
    0
    karadev
    hello colleagues, I would like to congratulate you on the outstanding work on making the processor on my assignment - 18F47k42-8192 SRAM. the processor is extremely good as the rest of the same family. we already have several units and tested the new 40-pin version.

    You are talking to other users of Microchip products on this forum, not Microchip themselves, so the flattery is wasted! ;)

    the circuit has two control ports, and because the signals from the different frequency generations have been collapsed, we have separated the separate ports to send separate signals to the managed equipment.

    As jtemples has mentioned, the problem is in YOUR CODE, which you didn't bother to post.
    You are almost certainly writing to bits in the PORT register rather than the LAT register, which is how you are supposed to do it. We wouldn't have to guess if yo just showed the actual code, but your use of terms "RC0" and "RC2" is a giveaway, when you should have been writing to LATC0 and LATC2.
    If you want to find out why, search this forum for thousands of references to "RMW" or "Read Modify Write"
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #5
    coffee critic
    Super Member
    • Total Posts : 238
    • Reward points : 0
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/09 16:10:46 (permalink)
    +1 (1)
    He probably hasn't cleared the slew rate bits either.

    n_*$
    #6
    karadev
    New Member
    • Total Posts : 17
    • Reward points : 0
    • Joined: 2012/07/20 02:23:59
    • Location: 0
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/10 09:29:34 (permalink)
    +1 (1)
    hmmm, this SLEW rate is new for me. i check the pdf and for 46k20 and for new 47k42 and this register is have in this two procesors. but info about for what is slew rate and for what is using this register is too short. i will be a very glad if someone can explane me a little more about this slew rate register, what is for in procesor and how i can get max speed in generation of all pins in same port or lat. and what this word SLEW means exactly ? if is better can show some chart like mine to be more clear explanation :) thanks in advance and best regards for all who read my post and will help me :)
    #7
    davekw7x
    Entropy++
    • Total Posts : 1530
    • Reward points : 0
    • Joined: 2012/01/16 12:01:07
    • Location: Left Coast, USA
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/10 14:33:23 (permalink)
    +2 (2)
    I will not try to address the points of your original post, but maybe I can shed a little light on "Slew Control" as applied to a PIC 'K42 MCU.
     
    In electronics, the "slew rate" of a signal is referring to the time it takes to change from one voltage level to another.
    See https://en.wikipedia.org/wiki/Slew_rate

    For analog applications, slew rate of an Op Amp might be expressed in Volts/usec

    For digital applications, the slew rate might be expressed as rise time and fall time for a given logic specification.

    In the 'K42 family, by default, output pin drivers are set to limit the slew rate.  If your outputs do not require a fast slew rate, limiting the rise time and fall time can give lower EMI (ElectroMagnetic Interference).  For faster rise and fall times your program can turn off the slew rate control for the individual pins.

    I'll observe the rise and fall times of two output pins on my PIC18F27K42 plugged into a curiosity board.  I'll use RA4 and RA5, which are connected through 1K resistors to LEDs.  Actual rise and fall times in "real" applications will, of course, depend on circuit loading.

    I'll give each one a couple of pulses as fast as they can toggle and observe the difference that is made by enabling or disabling Slew Rate Control.

    On my modest (70 MHz) 'scope, rise and fall times with slew rate control off seem to be about 10 ns.

    With slew rate control on, rise and fall times are something greater than 20 ns.

    Here's the program.


    // PIC18F27K42 Configuration Bit Settings

    // 'C' source line config statements

    // CONFIG1L
    #pragma config FEXTOSC = OFF    // External Oscillator Selection (Oscillator not enabled)
    #pragma config RSTOSC = HFINTOSC_64MHZ// Reset Oscillator Selection (HFINTOSC with HFFRQ = 64 MHz and CDIV = 1:1)

    // CONFIG1H
    #pragma config CLKOUTEN = ON    // Clock out Enable bit (CLKOUT function is enabled)
    #pragma config PR1WAY = OFF     // PRLOCKED One-Way Set Enable bit (PRLOCK bit can be set and cleared repeatedly)
    #pragma config CSWEN = ON       // Clock Switch Enable bit (Writing to NOSC and NDIV is allowed)
    #pragma config FCMEN = ON       // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor enabled)

    // CONFIG2L
    #pragma config MCLRE = EXTMCLR  // MCLR Enable bit (If LVP = 0, MCLR pin is MCLR; If LVP = 1, RE3 pin function is MCLR )
    #pragma config PWRTS = PWRT_64  // Power-up timer selection bits (PWRT set at 64ms)
    #pragma config MVECEN = ON      // Multi-vector enable bit (Multi-vector enabled, Vector table used for interrupts)
    #pragma config IVT1WAY = OFF    // IVTLOCK bit One-way set enable bit (IVTLOCK bit can be cleared and set repeatedly)
    #pragma config LPBOREN = OFF    // Low Power BOR Enable bit (ULPBOR disabled)
    #pragma config BOREN = SBORDIS  // Brown-out Reset Enable bits (Brown-out Reset enabled , SBOREN bit is ignored)

    // CONFIG2H
    #pragma config BORV = VBOR_2P45 // Brown-out Reset Voltage Selection bits (Brown-out Reset Voltage (VBOR) set to 2.45V)
    #pragma config ZCD = OFF        // ZCD Disable bit (ZCD disabled. ZCD can be enabled by setting the ZCDSEN bit of ZCDCON)
    #pragma config PPS1WAY = OFF    // PPSLOCK bit One-Way Set Enable bit (PPSLOCK bit can be set and cleared repeatedly (subject to the unlock sequence))
    #pragma config STVREN = ON      // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
    #pragma config DEBUG = OFF      // Debugger Enable bit (Background debugger disabled)
    #pragma config XINST = OFF      // Extended Instruction Set Enable bit (Extended Instruction Set and Indexed Addressing Mode disabled)

    // CONFIG3L
    #pragma config WDTCPS = WDTCPS_31// WDT Period selection bits (Divider ratio 1:65536; software control of WDTPS)
    #pragma config WDTE = OFF       // WDT operating mode (WDT Disabled; SWDTEN is ignored)

    // CONFIG3H
    #pragma config WDTCWS = WDTCWS_7// WDT Window Select bits (window always open (100%); software control; keyed access not required)
    #pragma config WDTCCS = SC      // WDT input clock selector (Software Control)

    // CONFIG4L
    #pragma config BBSIZE = BBSIZE_512// Boot Block Size selection bits (Boot Block size is 512 words)
    #pragma config BBEN = OFF       // Boot Block enable bit (Boot block disabled)
    #pragma config SAFEN = OFF      // Storage Area Flash enable bit (SAF disabled)
    #pragma config WRTAPP = OFF     // Application Block write protection bit (Application Block not write protected)

    // CONFIG4H
    #pragma config WRTB = OFF       // Configuration Register Write Protection bit (Configuration registers (300000-30000Bh) not write-protected)
    #pragma config WRTC = OFF       // Boot Block Write Protection bit (Boot Block (000000-0007FFh) not write-protected)
    #pragma config WRTD = OFF       // Data EEPROM Write Protection bit (Data EEPROM not write-protected)
    #pragma config WRTSAF = OFF     // SAF Write protection bit (SAF not Write Protected)
    #pragma config LVP = ON         // Low Voltage Programming Enable bit (Low voltage programming enabled. MCLR/VPP pin function is MCLR. MCLRE configuration bit is ignored)

    // CONFIG5L
    #pragma config CP = OFF         // PFM and Data EEPROM Code Protection bit (PFM and Data EEPROM code protection disabled)

    // CONFIG5H

    // #pragma config statements should precede project file includes.
    // Use project enums instead of #define for ON and OFF.

    #include <xc.h>

    #define _XTAL_FREQ 64000000UL

    #define LED1 LATAbits.LATA4
    #define LED1_TRIS TRISAbits.TRISA4
    #define LED1_SLEWCON SLRCONAbits.SLRA4

    #define LED2 LATAbits.LATA5
    #define LED2_TRIS TRISAbits.TRISA5
    #define LED2_SLEWCON SLRCONAbits.SLRA5

    void main()
    {
        LED1_TRIS = 0;
        LED2_TRIS = 0;
        
        // Turn off Slew Rate Control, so LED1 will have faster edges
        LED1_SLEWCON = 0;
        // Default is 1, so this is not really necessary
        // Turn on Slew Rate Control, so LED2 will have slower edges
        LED2_SLEWCON = 1;
        
        while (1) {
            LED1 = 1;
            LED1 = 0;
            LED1 = 1;
            LED1 = 0;
            LED2 = 1;
            LED2 = 0;
            LED2 = 1;
            LED2 = 0;
            __delay_us(5);
        } // End of main loop
    } // End of main())


    In the 'scope shot, Trace 1 is LED1, Trace 2 is LED2. (That's logical, right?)

    I just (sloppily) hooked a couple of wires from the 'scope probes to headers on the Curiosity board.  Didn't try to terminate them properly, so there is some ringing on the signals, but I think you can get the point.


    Regards,

    Dave
    Footnote:
    For people who didn't get the point, the observation is that the rate-limited signals are more "civilized,"  That is, no ringing on Trace 2 signal means that it is less likely to generate EMI.
    post edited by davekw7x - 2018/08/10 18:14:30

    Attached Image(s)


    Sometimes I just can't help myself...
    #8
    qɥb
    Monolothic Member
    • Total Posts : 3329
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: 18F27/47K42 wrong generated signals on same port B 2018/08/10 22:57:04 (permalink)
    +1 (1)
    karadev
    hmmm, this SLEW rate is new for me. i check the pdf and for 46k20 and for new 47k42 and this register is have in this two procesors. but info about for what is slew rate and for what is using this register is too short. i will be a very glad if someone can explane me a little more about this slew rate register, what is for in procesor and how i can get max speed in generation of all pins in same port or lat. and what this word SLEW means exactly ? if is better can show some chart like mine to be more clear explanation :) thanks in advance and best regards for all who read my post and will help me :)

    Dave has addressed what slew rate is, but really, for your application it probably wouldn't matter if you were addressing the correct ports.
    You STILL have not cleared up what ports registers you are writing to, or shown any of your source code.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #9
    karadev
    New Member
    • Total Posts : 17
    • Reward points : 0
    • Joined: 2012/07/20 02:23:59
    • Location: 0
    • Status: offline
    NO PROBLEMS ANY MORE :) 2018/08/14 12:24:02 (permalink)
    0
    NO PROBLEMS ANY MORE :) i want to thanks to any one who reply of my problem. like a here a mate say about for slew rate registers, i null them and all is goin fine in logic charts :). i check and pdf of 18F46K20 and actualy same register was and there. null and them in 5 minutes was enough to see the good result of analyzer graphics. :)
     
    all works fine. one more time i want to thanks to all of you, and i am shure for further if i have some problems can be sure for your help :)
     
    :)
    #10
    qɥb
    Monolothic Member
    • Total Posts : 3329
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: NO PROBLEMS ANY MORE :) 2018/08/14 13:13:56 (permalink)
    +2 (2)
    Is that all you changed?
    You still have not answered if you have fixed how you are writing to the pins.
    If you are still writing to the PORTx registers, then you have just temporarily masked the problem. Board changes, such as heavier loads or more capacitance on a pin, could make the problem come back.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #11
    Jump to:
    © 2018 APG vNext Commercial Version 4.5