• AVR Freaks

Hot!EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association

Author
uaz
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2015/06/22 20:53:20
  • Location: 0
  • Status: offline
2016/05/25 03:27:25 (permalink)
0

EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association

Hi,
 
PIC32MZ has 4 chip select pins (EBICS0-EBICS3) but only 3 Ready pins (EBIRDY1-EBIRDY3).
Does this mean that if we are using EBICS0, we don't have any EBIRDY pin available?
 
An example in figure 47-5 of page 15 of the reference manual shows that EBICS0 is being used together with EBIRDY1.
On the contrary, in the timing diagram of page 21, we can see that EBICSx is being used with EBIRDYx. So I suppose 'x' should be the same number both for EBICS and EBIRDY.
 
Can anyone help me clarify this?
 
Thanks!
UAZ
#1

17 Replies Related Threads

    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/24 18:05:03 (permalink)
    0
    Hi there!

    Did you ever figure out an answer to this? I found it unclear on how EBIRDYx lines (1-3) are associated with EBICS0-3) just like you and wound up here.
     
    I'm modifying my code so it no longer uses page mode to talk to my FPGA due to the fact that there is no reliable PBCLK8 output (I was trying to generate it on the FPGA and phase lock it to the data transitions but it was flaky).
     
    Silly me thinking that going to another mode on the EBI and using the READY lines was a solution, but I'm trying anyway. So far I can get the processor to freeze by using edge mode but no idea which ready line it's looking at.
     
    Anyone figure this out?
    #2
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/24 18:08:58 (permalink)
    0
    "The device associated with register set ‘x’ is a data-ready device, and will use the EBIRDYx pin."
     
    Just found this in the ebi documentation. I would then assume that using EBISMT1 would cause EBIRDY1 to be used. It would then be possible to point EBIMSK0 at EBISMT1  and have the diagram you say is contradictory.
     
    Trying this idea seems to indicate that even this isn't the right answer. But did we expect it to work? not me.
     
    I'll let you know if I figure it out. 
    post edited by tj256 - 2016/07/24 18:23:55
    #3
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/24 19:26:09 (permalink)
    0
    It seems that you have to have EBIRDYLVL = 0 set or it doesn't work. With that setting, it is not working as I expected. I tied all the EBIRDY lines together to do the test, and so far I can't figure out how the association is made between the two. I don't know if EBISMT0 has a ready. Haven't tried. But I get a "freeze" if I don't toggle and using EBISMT1. Now this is only a hackey test where I put a square wave on the ready signal. Without that, it hangs the system. That's a good sign I think.
     
    Talk about vauge. Does anyone use the EBI????

    Honestly, I've been infuriated with microchip over the numerous bugs and issues in the documentation that years later aren't fixed. I suspect this is yet another. Hopefully I can hack my way around this and never use another product from them again.
    #4
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/24 22:23:10 (permalink)
    0
    More info:
     
    I have EBICS0 and EBICS1 both set up and using regsel 0, memtype 1. RDYMODE = 1 and RDYLEVEL = 0. It appears that memory accesses do indeed freeze waiting for a transition on ready, however BOTH EBIRDY1 and EBIRDY2 must see a transition. One or the other won't cut the mustard. Note that this is with ALL EBICSx pins enabled for use.
     
    If I enable just one, the story gets stranger....
     EBIRDYEN2 = 1 causes the system to wait for a transition on EBIRDY1 ( device on CS0)
     EBIRDYEN3 = 1 causes the system to wait for a transition on EBIRDY2 ( device on CS0)
     
    If I turn back on device on CS1 this continues to hold, but the device on CS1 will wait for the same ready pin. 
     
    I don't know what to make of this. None of these tests are complete because I'm not running data through, but I'm not seeing a sensible relationship between EBIRDYx and the devices on CS0 and 1. If I have more than one ready signal, both devices wait on both signals. If I have only one. Both wait on that one. I don't know if microchip tested with >1 device. 
     
    If there's a way do do this, it isn't in the datasheets. I have to call it. Another busted device on a busted platform. Now I am probably going to spend another month rewriting my EBI code, with many sleepless nights wondering if it's even going to work in the end.  
     
    God I miss microchip circa 1998. What happened.
     
     
     
     
    post edited by tj256 - 2016/07/24 23:17:56
    #5
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/25 08:08:24 (permalink)
    0
    For what it's worth to anyone:
     
    I was able to get it to work, but it has been inconsistent. I have seen BOTH these situations at random between power cycles (not reboots):
    - Device on CS0 and CS1 both need only EBIRDY1 asserted to release the system
    - Device on CS0 and CS1 both need both EBIRDY1 and EBIRDY2 asserted to release the system
     
    It is the worst case: Inconsistent. But I seem to be okay if I wire EBIRDY1 & 2 together  and have both my devices toggle both. I don't think this is the intended design, but it's the way it works. I think this is another silicon bug.
     
    Also, I found a silicon bug in the tRC delay + cache over a year ago. Microchip has not bothered to put it in the Errata. I suspect EBI bugs are being ignored.
    #6
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/25 08:40:14 (permalink)
    0
    I take it all back. It's broke. Read listens to the EBIRDY while write ignores it. I give up.
     
    UPDATE: I fiddled with tRC and the other timings. Apparently having these set to zero causes this new issue. 
     
    I think I finally have my fix!!! I've always suffered with EBI due to no clock. It seems the answer is simple: Use the ready signal as the clock TO the pic (pulse high to get the next word) and further you can run the EBI at 100 mhz (yes you can! look at the datasheets) so the timing isn't all that bad.
     
    I don't want to scream victory after a year of pain and suffering with EBI but it looks like there may be a way out of this nightmare.
     

     
    // Enable address lines [0:23]
    CFGEBIA = 0x80FFFFFF;
    CFGEBICbits.EBIDEN0 = 1; // EBI Data Lower Byte Pin Enable bit
    CFGEBICbits.EBIDEN1 = 1; // EBI Data Upper Byte Pin Enable bit
    CFGEBICbits.EBICSEN0 = 1; // Chip select enable
    CFGEBICbits.EBICSEN1 = 1; // Chip select enable
    CFGEBICbits.EBICSEN2 = 1; // Chip select enable
    CFGEBICbits.EBICSEN3 = 1; // Chip select enable
    CFGEBICbits.EBIBSEN0 = 0; // EBIBS0 Pin Enable bit
    CFGEBICbits.EBIBSEN1 = 0; // EBIBS1 Pin Enable bit ** NOT USING BS0-BS1 **
    CFGEBICbits.EBIOEEN = 1; // EBIOE Pin Enable bit
    CFGEBICbits.EBIWEEN = 1; // EBIWE Pin Enable bit
    // Set up EBIRDY
    // CAUTION: These seem to be all mixed up and slightly busted. Verify by doing a memory access with RDY low. CPU should freeze.
    // - EBIRDYLVL must be 0 or it doesn't seem to see the ready signal.
    // - There is no sane association between ready line and chip select, nor any way to control it that I've found. (trial and error)
    // - Sometimes only EBIRDY1 is enough. Sometimes you need 1&2. So we'll stick with that.
    //
    CFGEBICbits.EBIRDYLVL = 0; // Use LEVEL detect
    CFGEBICbits.EBIRDYEN1 = 1; // "EBIRDY1 enable"
    CFGEBICbits.EBIRDYEN2 = 1; // "EBIRDY2 enable"
    CFGEBICbits.EBIRDYEN3 = 0; // "EBIRDY3 enable"

    CFGEBICbits.EBIRDYINV1 = 0; // If set, EBI ready 1 is active low.
    CFGEBICbits.EBIRDYINV2 = 0; // If set, EBI ready 2 is active low.
    CFGEBICbits.EBIRDYINV3 = 0; // If set, EBI ready 3 is active low.
    //Keep default data width to 16-bits
    EBISMCON = 0x00000000;
    //Connect CS0 & CS1 to physical address 0xC0000000 and 0xC1000000 for CACHED SDRAM
    EBICS0 = 0x20000000;
    EBIMSK0bits.MEMSIZE = 9; // 16MB
    EBIMSK0bits.MEMTYPE = 1; // 1:SRAM (2:NOR-Flash)
    EBIMSK0bits.REGSEL = 0; // Which EBITMGRx
    EBICS1 = 0x21000000;
    EBIMSK1bits.MEMSIZE = 9; // 16MB
    EBIMSK1bits.MEMTYPE = 1; // 1:SRAM (2:NOR-Flash)
    EBIMSK1bits.REGSEL = 0; // Which EBITMGRx

    // Timing for CS0&CS1. PB8 Clock is 50 mhz / 20 ns.
    EBISMT0bits.RDYMODE = 1; // Use ready mode
    EBISMT0bits.PAGEMODE = 0; // NEVER Use PAGE mode (seems to be for READS only. tRC occurs at the start and any WRAPPING. So accessing a 16 byte unaligned address for the first time will cause a tRC, reads, wrap, and another tRC! BUG!)
    EBISMT0bits.PAGESIZE = 1; // 8 word page
    EBISMT0bits.TBTA = 1; // Data Bus Turnaround Time bits - Clock cycles (0-7) for static memory between read-to-write, write-to-read, and read-to-read when Chip Select changes
    EBISMT0bits.TWP = 1; // Write pulse width is TWP + 1 clock cycle.
    EBISMT0bits.TWR = 1; // Write Address/Data Hold Time bits
    EBISMT0bits.TAS = 1; // Write Address Setup Time bits - Clock cycles for address setup time. A value of ‘0’ is only valid in the case of SSRAM
    // FOR READS: TRC is the read to read time. TPRC is the initial time.
    EBISMT0bits.TRC = 1; // Read Cycle Time bits - Read cycle time is TRC + 1 clock cycle. (min 20 ns)
    EBISMT0bits.TPRC = 0; // Read cycle time is TPRC + 1 clock cycle (min 20 ns / 1)

     
    I must now conclude that I must be the first person ever to use EBI ready! Why else are these forums devoid of others noticing this issue and working through it? I now leave you to your broken processors. Enjoy :)
    post edited by tj256 - 2016/07/25 10:57:53
    #7
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/07/26 16:42:18 (permalink)
    0
    Final note:
     
    I finished rewriting my EBI to FPGA interface and it works. The reason I did this in the first place was simply that I adopted PIC32 early on when the roadmap said DDR/SDRAM was forthcoming. I planned on having my project mostly done on the dev kit and adding that functionality later. Of course, it never happened. So I hastily made boards with an FPGA to glue ram to my processor to "save the day" (or else we'd never ship product and have to start over).
     
    Soon I discovered there was NO CLOCK OUTPUT ON EBI and NO APPARENT WAY TO OUTPUT IT. THis severely limits it's usefulness since there is no way to register data on an edge without a clock. For a year I struggled with flaky behavior after spending a good month hacking an exertnal clock generator / phase lock to get a bit clock. Internally in the EBI I saw evidence that there was enough jitter that my phase locked clock wasn't accurate enough at the data rates I needed (I trusted the datasheet-- my design needed 100 mbits/sec logging to ram at least 32mb in size).
     
    So that brings me to this thread when I decided to tackle this issue. I wound up moving from "page mode" and tRC + cache "on" for the address space in order to batch up the 16 byte transactions. tRC lets the EBI assert the address while the FPGA goes and transacts on SDRAM and presents the data after tRC. This sort of worked, but again, no clock and sync issues galore. (WHO DESIGNS A FRIGGIN BUS WITH NO CLOCK???)
     
    Tried to work with microchip to no avail and spent many days total compiling information for them to fix an issue with tRC-- to which after waiting almost a year ended up with them asking "How many units are you going to sell?". My rage to that question was answered with "I'm just trying to make a case to my boss!" I don't care who finds a bug. Fix it! It could be the trash man for christ sake. All customers suffer from bugs. My how microchip has fallen from the days I used to have of having my bugs fixed or at least winding up with published workarounds so at least it was worth it to use tech support. (And no, it didn't make the Errata either so beware of that one).
     
    I held my breath and rewrote everything with the idea of running EBI at 100 mhz and using ready as a way for my FPGA to become the "master of the clocks" and basically present data and toggle ready (edge mode) at a rate of 1/2 EBI clock (50 mhz).
     
    Lo and behold it worked. I'm sitting here after an hour+ of hitting the bus hard and no errors. So... to anyone out there needing to glue to the PIC via EBI... YES it works. But it isn't without issues. Don't set timing registers to 0 or you will have trouble. There is strangeness as I mentioned earlier with the ready vs CSx associations. But if you're willing to stick with it you will eventually get it to work.
     
    I have to say that this battle plus the many other ones I've waged with the PIC32 has resulted in me swearing this and any future products from microchip off. I've lost all trust and faith in this company. I may ship my product after all but from broken tools, NUMEROUS broken hardware issues, not getting results from support, and watching release after release of things like harmony and mplab... I just can't deal with this anymore. So this is my last journey with PIC. So sad.
     
    post edited by tj256 - 2016/07/26 16:49:27
    #8
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/17 20:03:46 (permalink)
    0
    It's been some time-- and I've had plenty of time to convince myself EBIRDY works, but I continue to be convinced that something is broke with it in terms of mapping.
     
    I just added 2 devices on CS2 and CS3. Now the question is simply which ready should I use? Amazingly without setting EBIRDY to "in use" (it's set to 0 in the registers) it somehow still waits for the ready lines I'm already using (1/2). 
     
    I'm not sure. I want to say that the mapping goes according to the value of REGSEL but it doesn't seem to work that way since sometimes EBIRDY2 needs to be active for a "ready" to be registered and the cpu released for a transaction on CS0.
     
    I guess we'll never know.  But hopefully they won't fix it because it will cause me to break!
     
    My advice is to either use ready on all devices or no devices. It seems using ready at all causes it to be used for all chip selects. So I just tie them all together and treat them as a single signal. That seems to be the most reliable way.
     
    I've hammered this thing for a few weeks running continuously transferring 15mb/sec  to SDRAM and I think I've finally got it working good enough to try to forget the pain I had to go through.  
     
    It seems like anyone that uses a PIC32MZ had better put an FPGA on their board to work around the broken shizzle. But like me you may have to deal with more broken to fix the broken :) At least my project is saved!
    #9
    NorthGuy
    Super Member
    • Total Posts : 6176
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/17 21:05:46 (permalink)
    0
    I don't think the documentation implies any sort of relationship between CS lines and RDY lines. They seem to be completely unrelated to each other.
    #10
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 08:57:41 (permalink)
    3 (1)
    NorthGuy
    I don't think the documentation implies any sort of relationship between CS lines and RDY lines. They seem to be completely unrelated to each other.

    They do imply it in the sense that each device can either have ready or no ready signal. So given there are multiple ready lines, why wouldn't there be an association?
     
    #11
    NKurzman
    A Guy on the Net
    • Total Posts : 18791
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 09:27:57 (permalink)
    3 (1)
    Is the an EC chip? or an EF?
    They pretty much abandon the EC version.
    I would hope better for the EF.
    An I am sorry to hear that Hardware support is lacking too.
    The People that made the chip should know how it works.
    I hope they are not just slapping libraries together.
    #12
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 09:45:18 (permalink)
    3 (1)
    I'm using the EC-- uhoh.
    #13
    NorthGuy
    Super Member
    • Total Posts : 6176
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 10:39:02 (permalink)
    4 (1)
    tj256
    They do imply it in the sense that each device can either have ready or no ready signal. So given there are multiple ready lines, why wouldn't there be an association?



    It would be more logical if there was an association and each CS pin had its own RDY pin, but it doesn't mean that there is an association, and nothing of that sort is mentioned in the (very scarce) docs. And there's no empirical evidence of any such association in your experiments.
     
    Looks like you simply connect a device to any enabled RDY pin, and if the device is CS'd then it drives the RDY pin, while the devices which aren't CS'd don't drive the RDY pins they're connected to. Thus the MZ can listen to all enabled RDY pins without making any distinction. If the devices put their RDY pins into high impedance state while not CS'ed then you would connect them all to a single RDY pin plus a pull-down resistor. If the devices keep their RDY pins low (or high) when not CS'ed then, obviously, you cannot connect them all to a single RDY pin without any extra hardware. In such cases, you can use a separate RDY pin for each device. I think this was the intent for multiple RDY pins.
     
    Instead of CS (or in addition to CS), you could select different devices with address lines or with any other means, so there could be more than 4 devices. You would need to provide an access to an RDY pin for all such devices.
     
    #14
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 11:07:51 (permalink)
    0
    This idea makes the most sense given the observations, I agree. However, I didn't consider this possibility because such an implementation would be pretty naive. But then again, that would not surprise me.
     
    The reason I say this is because if you are using DMA on a device with a ready pin and the device isn't ready, another device directly accessed via the CPU directly (also with ready) should be able to proceed. But now that I think about it more, you couldn't even have this situation, since presumably the bus is tied up. I think you may be right.
     
    If one device is blocked via the ready, the CPU is halted. So since the CPU can't access >1 device simultaniously, what you suggest would make sense.
     
    It is odd that sometimes all enabled ready pins must be "active"-- but not always.  With ready 1 and 2 enabled, sometimes just 1 going high is enough. Sometimes 1 and 2 are required. Perhaps there is an issue with this that should be in the errata but I'm not going to go barking up that tree again.
     
    Thanks for the thoughts! It does fit with observation. That said, I wouldn't have implemented it this way and wish they hadn't.
     
     
     
     
    post edited by tj256 - 2016/08/18 11:10:43
    #15
    NorthGuy
    Super Member
    • Total Posts : 6176
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 11:31:33 (permalink)
    3 (1)
    tj256
    It is odd that sometimes all enabled ready pins must be "active"-- but not always.  With ready 1 and 2 enabled, sometimes just 1 going high is enough. Sometimes 1 and 2 are required. Perhaps there is an issue with this that should be in the errata but I'm not going to go barking up that tree again.



    This is very odd. You're probably one of the few people in the world who's attempting this connection and it wouldn't be a big surprise if Microchip haven't tested it fully. May be it's different in EF. Also it could be some sort of timing issue. In addition, they have edge vs level triggering - so there's still plenty of things to try :)
    #16
    NKurzman
    A Guy on the Net
    • Total Posts : 18791
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2016/08/18 11:46:40 (permalink)
    3 (1)
    If it is working, not a problem, they should keep making chips as long as they are buyers.
    If it works and you are close to shipping, then stick with it.
    You may want to build some boards with the EF Version and try it if you will be working on it for a while.
    I heard they will not be updating the EC.  It is what it is.
     
    Note there will be a PIC32 MZ with a Graphics engine and that will have and SDRAM interface.
    I do not know the details, just it is in Beta.
    #17
    wx4p
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2020/06/25 08:44:01
    • Location: 0
    • Status: offline
    Re: EBI Ready (EBIRDYx) pins and Chip Select (EBICSx) pins association 2020/06/30 08:54:15 (permalink)
    0
    In case anyone else has this question, here's what we observed through trial and error of the register settings after not being able to find a clear answer elsewhere:
     
    Even though the numbering doesn't match (1,2,3 vs 0,1,2) the EBIRDYx signals are mapped to the Timing Register sets:  Chip selects mapped to EBITMGR0 use EBIRDY1 if RDYMODE is enabled, EBITMGR1 ==> EBIRDY2, and EBITMGR2==> EBIRDY3,
    #18
    Jump to:
    © 2020 APG vNext Commercial Version 4.5