infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 11 to 17 of 17

Thread: Migration from XMC4500 to XMC4700

  1. #11
    New Member New Member ibuchbau is on a distinguished road
    Join Date
    Jan 2015
    Posts
    13
    Points
    70
    Hi Jesus

    Here an short update from our side

    1. On our Testproject we do net see any DMA Errors when the Trap Occurs

    2. We have produced 50 new PCB with the XMC4500 and they all work fine.
    We have 20 PCBs with the XMC4700 which all show this trap problem.
    Except the Microcontroller ther are all components the same on these PCBs.
    They are even most from the same tray/package unit.

    Even it is a satisfying workaround for us to use the XMC4500 we would be very interested
    in getting our application to work with the XMC4700. I can only imagine that we are doing something wrong
    with the XMC4700 (DMA Konfiguration, EBU Konfiguration,..) or there is an Errata we don't know.

    So as I said we would be very interested in getting the XMC4700 working, so I can give you any information
    you want for analyzing the problem. Maybe it is useful that you get a remote session to one of our development
    computers or you got some samples from our hardware or some other information like the schematic.

    Thank you for your help

    Ingo

  2. #12

    Error Traps during EBU access

    Hello Jesus,

    while searching the Internet for EBU Bus Faults with the XMC4700, I found your Forum thread.
    The thing is, that we are facing a very similar behaviour on the XMC4700 and the XMC4500 and we are interested if you found a workaround/solution for the described problem.

    Here are some Infos about our configuration:
    We connected a CPLD and an MRAM to the EBU via Chip Select.
    The timing was verified with an oscilloscope, it worked perfectly without bus fault exceptions on the XMC4500 but shows exceptions on the XMC4700 sporadically.
    We access the EBU via CPU.

    Minor changes in our code (even in functions not called before the bus fault exceptions) results in different behaviour of the bus fault exceptions.

    Can you help me too with this issue?

    Thanks in advance
    Karl

  3. #13
    New Member New Member ibuchbau is on a distinguished road
    Join Date
    Jan 2015
    Posts
    13
    Points
    70
    Hi Karl

    Just a few informations for you

    >> Here are some Infos about our configuration:
    >> We connected a CPLD and an MRAM to the EBU via Chip Select.
    >> The timing was verified with an oscilloscope, it worked perfectly without bus fault exceptions on the XMC4500 but shows exceptions on the XMC4700 sporadically.
    >> We access the EBU via CPU.
    We have connected a SRAM, a PSRAM, a NAND Flash and a NOR Flash with 16 Bit multiplexed Bus.
    The Bus Faults can be seen on all Chip selects sporadically, but more often when acess is done via DMA than whe the Access is done via CPU.
    Do you also use 16Bit demultiplexed Bus ?

    >>Minor changes in our code (even in functions not called before the bus fault exceptions) results in different behaviour of the bus fault exceptions.
    It is exactly the same in our projects. A minor change in the software results in a different behaviour, so this is practically not possible to debug..

    Our workaround so far is to use the XMC4500. We tried some changes in the EBU Configuration but with no changes in the behaviour.
    It is also very difficult to get a mini project for Jesus so that he can repoduce it because of the behaviour described above.

    Regards
    Ingo

  4. #14

    New findings with EBU bus faults

    Hi Ingo and Jesus,

    Ingo, thank you for your response.

    Do you also use 16Bit demultiplexed Bus ?
    No, we only use multiiplexed bus including A16 and A17 to have 18 address lanes.

    It is also very difficult to get a mini project for Jesus so that he can repoduce it because of the behaviour described above.
    We managed to get a minimal project that shows the described behaviour.

    Jesus, I attached the project to this post, named "zebu.zip".
    The project shows a bus fault after about two seconds on our hardware.
    If you could use one of our test-Hardware stations let me know, i think we could easily send you one.

    We tried many different configurations on different Projects.
    Let me sum up our findings during testing:
    - We tested two configurations,
    Config 1: Setting the input clock to the EBU to synchronous mode to the AHB. The config is provided in the attached file "Zebu/cfg/ebu_cfg47.h"
    Config 2: Setting the input clock to the EBU to asynchronous mode to the AHB with Setting the EBUDIV divider in SCU_CLK.EBUDIV. This config is in the file zebu/cfg/ebu_cfg47_good.h.

    Config 1: The EBU_CLK equals the clock of the AHB, we tried 144 MHz and 120 MHz. We tried many changes with the remining timing parameters. We verified these on the oscilloscope and read and write accesses worked without errors but we had Bus Fault Exceptions regardless of the exact Settings.
    Config 2: The EBU_CLK is derived from the PLL with the divider SCU_CLK.EBUDIV. We set this divider with respect to fCPU either to 144 MHz: 8 or 120 MHz : 6.
    We found few bus faults with fCPU = 144 MHz and until now not a single bus fault with fCPU = 120 MHz.

    In our understanding, the reasons for the bus faults should not depend on external devices but on the internal AHB-Interface between the EBU and the Bus Matrix, so we tried changing the EBU-Clocking configuration and adapting the external Timings accordingly.

    Jesus could you please review our configuration and give a statement to the described, different behaviours between the configurations? Is Config 2 a hundred percent safe with 120 MHz?
    The thing is we need a 100% working configuration with no bus faults at all so that we can get to production with the XMC Controller.

    We found a similar Problem regarding bus faults on Cortex m cpus, see https://www.lpcware.com/content/foru...cd-display-tft
    The solution there seems to be to clock the "EMC", which basically complys with the EBU, with less than the Maximum fCPU clock. This is even stated in the reference Manual of this LPC Controller.
    Is there a similar hint for the XMC4700 EBU ?

    Thank you for your help

    Karl
    ?????

  5. #15
    Beginner Beginner Query1920 is on a distinguished road
    Join Date
    Jul 2018
    Posts
    7
    Points
    102.5
    Hello Ingo/Jesus,

    Did you happen to identify root cause for this issue ?
    Is there any known errate which is causing this issue ?

    I am seeing similar behaviour in XMC4700. I am trying to access FPGA and Flash memory over EBU.
    I get interrupt from FPGA at variable frequency and i read data from FPGA and write data in Flash memory. All these operation is happening over EBU.
    If i comment write to flash memory i don't see any issues which proves me that arm processor is kind of able to handle nested interrupts from FPGA. But when i perform write operation in conjunction with
    serving interrupt from FPGA , randomly my code crashes into Bus fault exemption. If i track down what is causing issue i see everytime my code goes to Flash write function and then to
    interrupt handler.

    I have spent lot of time to investigate this issue but not able to get to root cause,

    Could you please provide me some information on how did you resolve your issue ?
    That might help me to debug my issue.

    Looking forward to hear back from you.

    Any help here is much appreciated !

  6. #16
    New Member New Member ibuchbau is on a distinguished road
    Join Date
    Jan 2015
    Posts
    13
    Points
    70
    Hello Query1920

    The problem we had was Flash Double Bit Errors on Internal Flash when doing EBU Access. This was caused by noise from the EBU Pins.
    We solved it by reducing driver strength.

    Below see the Errara I got from Jesus.
    I hope this helps

    PORTS_CM.H002 Class A2 pins GPIO driver strength configuration

    Before activating the push-pull driver, it is recommended to configure its driver strength and slew rate according to its pad class and the application needs using the Pad Driver Mode register (Pn_PDR).
    Selecting the appropriate driver strength allows to optimize the outputs for the needed interface performance, can help to reduce power consumption, and limits noise, crosstalk and electromagnetic emissions (EMI).

    There are three classes of GPIO output drivers:
    • Class A1 pads (low speed 3.3V LVTTL outputs)
    • Class A1+ pads (medium speed 3.3V LVTTL outputs)
    • Class A2 pads (high speed 3.3V LVTTL outputs, e.g. for EBU or fast serial interfaces)

    Class A1 pins provide the choice between medium and weak output drivers. Speed grade 6MHz.
    Class A1+ pins provide the choice between strong/medium/weak output drivers. For the strong driver, the signal transition edge can be additionally selected as soft or slow. Speed grade 25MHz.
    Class A2 pins provide the choice between strong/medium/weak output drivers. For the strong driver, the signal transition edge can be additionally selected as sharp/medium/soft. Speed grade 80MHz.

    If the output driver strength of Class A2 pins is configured as strong/sharp care need to be taken to avoid overshoots, undershoot and ringing that may lead to high radiated emissions and crosstalk.

    The high radiated emissions may lead to Bus Errors exceptions (or Hard Fault exception in case the Bus Error exception is not enabled) caused by a double bit error fail in a flash read access. Flash double bits errors are identified in the FLASH0.FSR register.

    Recommendation
    In general to avoid the high radiated emissions it is recommended the usage of damping resistors (10 ohms) between the high speed drivers and the transmission lines.
    It is also recommended to adapt the driver strength to the needs of the application, i.e. to drive a 25MHz signal strong/medium or strong/soft would be suitable lowering the potential overshoots and undershoots.

  7. #17
    Beginner Beginner Query1920 is on a distinguished road
    Join Date
    Jul 2018
    Posts
    7
    Points
    102.5
    Hi Ibuchbau,

    Thank you for the feedback, I created crash again on our system and saw Flash Single and Double bit error were set.
    Looks like same issue. So i reduced driver strength to strong/Medium instead of Strong/sharp and ran it in release mode and saw system crashing again. If i reduce strength to any value lower than strong/medim then my system don't see any signal on EBU lines.

    Is there anything else you did to resolve this issue apart from reducing driver strength ? Did you make any modification in hardware ?

+ Reply to Thread

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.