Forum Rule: Always post complete source code & details to reproduce any issue!
Page 43 of 43 FirstFirst ... 33 41 42 43
Results 1,051 to 1,073 of 1073

Thread: Teensy 4.0 First Beta Test

  1. #1051
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,835
    Again I am maybe not the best one to answer here.
    But one thing I noticed was:
    Code:
        CORE_PIN1_CONFIG = 0x12;
    Will set pin 1 to = 010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_TXD of instance: lpuart6

    Should probably be: 0x10 for 000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_TX of instance: flexcan2

    Page 451

  2. #1052
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,882
    yes they both should be 0x10 i’m sure the above was a typo (at least on my end both are ALT0 - 000

  3. #1053
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,201
    Quote Originally Posted by KurtE View Post
    Again I am maybe not the best one to answer here.
    But one thing I noticed was:
    Code:
        CORE_PIN1_CONFIG = 0x12;
    Will set pin 1 to = 010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_TXD of instance: lpuart6

    Should probably be: 0x10 for 000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_TX of instance: flexcan2

    Page 451
    tonton81 is right it should be 0x10. Was trying to get Can1 working on pins 22 and 23, but that didn't seem to work. Forgot to put it back to 0x10 when I posted it. Other than that it should work.

    Just seems pins 0 and 1 are funny when it comes to assigning alternate pins.

    Again my encoder test case seems to work with the other pins tested except for pins 0 and 1.

  4. #1054
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,835
    Maybe post encoder source and I will try to take look...

    Maybe dig up rover with encoders...

  5. #1055
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,882
    i’ve tested loopback mode and havnt been able to receive even with self reception enabled and listen only modes...
    if self reception is not working and the transmit buffers are all filled pending arbitration, its either pin or clocking issues, as those modes do not require bus activity, however, i will say i have a t3.2&3.5 randomly talking to each other over the same bus fine, i set those up before i started the t4 version

  6. #1056
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,201
    Quote Originally Posted by KurtE View Post
    Maybe post encoder source and I will try to take look...

    Maybe dig up rover with encoders...
    This was buried in an edit I did. EDIT: If you want to see the Encoder sketch that works on pins 6/7, and 2/3 I just posted it on GitHub, https://github.com/mjs513/WIP

    The encoder stuff is pretty much direct from the SDK example. Not the cleanest but just needed something working to test XBAR and the module with before I started on anything with quadrature encoders.

  7. #1057
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,066
    Quote Originally Posted by KurtE View Post
    ILI9341_t3n DMA Usage - Update Async


    If I output the same screen using DMA it comes out, but some of it appears to be corrupted slightly...
    Attachment 15695

    But getting closer - Note this output was using memory allocated using malloc, with the buffer being allocated on 16 byte alignment.
    Is the cache disabled?

  8. #1058
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,835
    Quote Originally Posted by Frank B View Post
    Is the cache disabled?
    Maybe dumb question how do you disable? I have tried both allocating by Malloc, and tried DMAMEM.

  9. #1059
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,066
    I wrote several posts about the need to modify its setting... (insider)

    Ok, its really needed to disable it or switch to write-through - will not work without that.
    We have to wait for a official solution by Paul.
    In the meantime, you can edit configure_cache() in startup.c:
    Code:
        SCB_MPU_RBAR = 0x20200000 | REGION(3); // RAM (AXI bus)
        SCB_MPU_RASR = MEM_CACHE_WT | READWRITE | NOEXEC | SIZE_1M;
    Malloc and DMAMEM both use the same memory area -> identical results.

  10. #1060
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,835
    Thanks @Frank B,

    Yep that got working.

    I remember reading about it awhile back, but getting harder to find things in this thread... thought a fix was already in. Wondering now about does it make sense to do dma in spi library,as user might expect to be able to use any memory address for RX or TX locations.

  11. #1061
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,066
    Well, "normal" RAM (for variables) is not cached.
    OCRAM (HEAP, DMAMEM) is cached. I've proposed a way to make DMAMEM uncached and keep HEAP cached.
    If a user wants to use HEAP - well.. he has to learn that there is a cache and DMA does access the underlying RAM, and not the cache.
    There are functions to flush the cache in the core.
    Last edited by Frank B; Yesterday at 10:17 PM.

  12. #1062
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,066
    Kurt, in my lib I have a funny effect:
    I have to copy the dmasettings twice:

    dmatx = dmasettings[0];
    dmatx = dmasettings[0];

    Nothing else helps - not asm("dmb"), not ("dsb"), not ("isb"), ..all three combined do not help, too. I even tried a delay.
    Dmatx is in normal RAM, which is not cached.
    I found this only by accident, after hours of trying to identify the problem that restarting the autorefresh always started with the last chunk of data.
    As soon I had this line twice, accidentally, it suddenly worked..

    Anybody got an idea?

  13. #1063
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,835
    Frank,
    Sounds pretty strange!

    Will play some with SPI.transfer code and see how what I need to do... Will keep it simple to start with. And then maybe try to look up what it takes to flush the cache... But right now busy with some other stuff...

  14. #1064
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,066
    Kurt: re: DMA/SPI
    The best solution I found so far to detect the end of a transfer is the magic Enterprise value:
    Code:
     while ((LPSPI4_SR & 0x1701) != 0x1701) {}; //TDF=1, WCF=1, FCF=1, TCF=1
    If you use the hardware-CS you migth want to add the MBF flag. It goes LOW shortly after the flags above. I found, for my software-cs it's not needed to wait for it.
    Last edited by Frank B; Today at 08:11 AM.

  15. #1065
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,066

    Bsp

    Page 1721:
    28.2 Overview
    This section provides an overview of the
    • NIC-301 (Network Inter-Connect) AXI arbiter IP
    The NIC-301 (by ARM Ltd.) is a configurable AXI arbiter between several masters
    and slaves. The NIC-301 IP is designed so that many configuration options are
    selected at the hardware design stage, determined by SoC characteristics and needs,
    while several other configuration options are software-controlled.
    This chapter covers in brief the NIC-301 while providing configuration details on the
    NIC-301 instances used in the chip. For complete details on the NIC-301 design, see the
    ARM specification, AMBAŽ Network Interconnect (NIC-301) Technical Reference
    Manual, version r2p3.


    NOTE
    The NIC-301 default settings are configured by NXP's board
    support package (BSP), and in most cases should not be
    modified by the customer. The default settings have gone
    through exhaustive testing during the validation of the part, and
    have proven to work well for the part's intended target
    applications. Changes to the default settings may result in a
    degradation in system performance.
    Do we have a TODO here ? What is the "BSP"?

  16. #1066
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,012
    Hi everyone. Sorry I've been so absent the last couple weeks. Still getting over this cold, but things are starting to return to normal.

    On the PJRC business side, Robin & I hired a new person who starts Tuesday, so there too things will soon be back to normal.

    Right now I'm reading through the last couple hundred messages I've missed on this thread (while limiting my forum activity to only basic tech support stuff).

    Quote Originally Posted by defragster View Post
    Paul - do you have a goal release date for Beta #8?
    Yes. I tried to merge all the pending pull requests Thursday & Sunday. Please let me know if I've missed any?

    Planning to do some testing and maybe some initial work on the USB stuff, then package up 1.46-beta8 late Monday or early Tuesday.

  17. #1067
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,371
    Fetched the latest CORES and it seems good - for what I tested ... micros ...
    And 8 port Serial Chaining with no DEBUG_PRINT_STUFF in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\debu g\printf.h to open Serial #4
    CROSSPOSTED with Paul - Glad you are feeling better - hope the new staff member up to speed quickly. Beta 8 sounds like fun - my notes above show it isn't broken

    Paul took the micros() change to cores - if you get that the T4_demo ... Syncron_Micros for fun LED flash and temp reading. On github at 600 MHz - but #define CHANGE_SPEED will cycle [200-800] MHz and works on the T4 I got.

    The Cores update gives 1us res for micros and elapsedMicros based on last systick. It demo's the ARM Synchronization primitives - easier to see in Syncron_isr which will run without cores update against IntervalTimer at 1000 or 100 us is anyone wants to look at getting safe (atomic like?) data updates across an _isr without killing interupts [this parallel code may fully not match the working micros code]. Thanks to FrankB for pointing the way on that. It seems to add only a couple/few cycles of overhead - mostly from it forcing data to be re-read when conditional detects interrupt occurrence. In the case of micros() time spent is about the same because of not doing int Off/On.

    With that Paul made the unused_interrupt_vector() weak like it was on T_3.x - so I'm going to look into a library with my assert and other tracing tools I started on _T3 to see if being stopped by a fault can expose info on what came before that with output to Serial# port. Hopefully including user input to issue commands [restart, bootloader, ...] - including calling a DUMP() function in user sketch to expose stuff that is too much to print when running.

    On T_3.x Paul had things like this to keep Serial alive to allow auto upload:
    Code:
      if (SIM_SCGC4 & SIM_SCGC4_USBOTG) usb_isr();
      if (SIM_SCGC4 & SIM_SCGC4_UART0) uart0_status_isr();
    Some note and the state of USB Serial suggests this is TBD ...

    KurtE for Serial# might this be the equivalent function to move Serial# data when faulted? ::
    Code:
    HardwareSerial::IRQHandler()

  18. #1068
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,012
    Quote Originally Posted by manitou View Post
    Nothing uses GPTn as far as I know ... which goes to Paul's need to have a "timers consumers list" to know what is using which timers (PIT, GPT, QTMR, flexPWM) ... IntervalTimer, Tone, PWM, IRremote ...
    Quote Originally Posted by luni View Post
    Really? Using a "precious" 32bit timer/counter for micros?
    My general plan has been to use both GPT to allow up to 10 IntervalTimer instances. The general idea was to configure both for free running mode (0 to FFFFFFFF at 24 MHz) and use the 3 comparators.

  19. #1069
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,201
    @Paul
    Glad things are back to normal and you are feeling better. If the cold is like anything I had its going to linger a while longer.

    @defragster
    Tim - Gave your T4_demo ... Syncron_Micros a try the other and was forgot to even check out the micros, was watching the Temp changes as speed changed Forgot to tell you too much else was going on.

    As for the assert function, you know I gave it a try and was working. But interestingly enough when I was poking around the sdk it had a version of a assert function in one of the other folders, if you want it I can post it.

    Mike

  20. #1070
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,012
    Quote Originally Posted by Frank B View Post
    Yes it was active, and USB is online.. so I don't know the reason.
    At very low clock speeds, the internal buses probably can't support USB packets at 480 Mbit/sec.

    I believe the USB PHY has a bit to restrict the hardware to only 12 Mbit/sec. We should probably set that if the speed is so slow.

  21. #1071
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,371
    Quote Originally Posted by mjs513 View Post
    ...
    @defragster
    Tim - Gave your T4_demo ... Syncron_Micros a try the other and was forgot to even check out the micros, was watching the Temp changes as speed changed Forgot to tell you too much else was going on.

    As for the assert function, you know I gave it a try and was working. But interestingly enough when I was poking around the sdk it had a version of a assert function in one of the other folders, if you want it I can post it.

    Mike
    Temp moves quickly up and down decided to make a thing to see - so good PJRC use of board to spread heat (of course this one wider than Teensy) or it wouldn't drop as fast - and the MCU gets busy and warms fast with extra cycles and volts.

    I did see your assert_t3 note - and I installed the NXP SDK and browsed enough to see they had an ASSERT - I'll go back to it to see if it adds anything or works better. Another ideas for debug - or ways to make faults or show helpful stuff - post or PM.
    Code:
    void __assert_func(const char *file, int line, const char *func, const char *failedExpr)
    {
        PRINTF("ASSERT ERROR \" %s \": file \"%s\" Line \"%d\" function name \"%s\" \n", failedExpr, file , line, func);
        for (;;)
        {}
    }

  22. #1072
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,012
    Quote Originally Posted by mjs513 View Post
    USING ALTERNATE DEFINITIONS OF PINS - HOW TO?

    Getting myself really confused on this one, trying to read the manual and testing. Looking at PINs 0 and 1 for instance the default is Serial1 (LPUART6). Now if I want to reassign it to XBARA or FLEXCAN. I was looking at the quadrature encoder module and it use the xbara pins for input. Anyway this is the process I think:

    1. Turn LPUART6 clock off (CCGR3)
    2. Disable the LPUART6 IRQ
    3. didn't see a way to update the vtable so guess that stays
    4. Update pin configurations, i.e.,
    Code:
    000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
    001 ALT1 — Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1
    010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_RX of instance: lpuart6
    and sion bit to enable
    5. Select input - output modes for pins, i.e.
    Code:
    IOMUXC_FLEXCAN2_RX_SELECT_INPUT for Flexcan
    xbar_connect  (saw this in pwm.c)
    6. Configure Flexcan2 or Xbar clocks
    7. Enable clocks with CCM_CCGR0 or CCM_CCGR2
    8. Almost forgot enable IRQs for XBAR or FLEXCAN2

    Still need to work some of the details but just want to see if this makes sense and I am on the right track.
    For most of the peripherals, you probably don't need to shut off their clock or fully disable them just to reassign their I/O pins. You DO need to shut off a peripheral if you're going to mess with its clock. I can tell you I managed to lock up the whole chip in strange ways just by messing with the UART clocks while the hardware was enabled. Great caution is needed when fiddling with any "CCM" stuff. So far I've not seen that sort of problem when just messing with the IOMUX settings.

    So far, I've only done limited experiments with XBAR, and only stuff inside the chip. You found the xbar_connect function I wrote while working with FlexPWM. Before I figured out how to turn off the fault inputs and properly clear fault status (which was a major frustration getting PWM to work... about 1 month before we started this beta test) I did use that code to control the PWM fault inputs. It did seem to work (and earlier versions you don't see definitely did not work, as evidence by lack of effect on those troublesome fault status bits).

    One of the great mysteries of this chip (at least to me) is why NXP didn't route the quadrature decoder signals to any pins, only to XBARA. I'm going to guess it was an oversight. So you have to use the XBAR, just to get pins connected to it. I have not actually done this, but here's my best guess from reading the reference manual.

    1: Make sure the relevant bits in IOMUXC_GPR_GPR6 are clear. They're supposed to default to all zeros at reset, so you can probably skip this step if you're not concerned any other code might have messed with that register. If you're going to try to just output from XBAR, then you must set the bit to 1 for whatever physical pin you'll use.

    2: Write to the IOMUX register. Whether the SION bit needs to be set is a good question. I really don't know, but my guess is SION should be 0 for XBAR use. If the mux was set to something other than GPIO (5), whether you would shut that peripheral off is a good question. My guess is you can probably ignore that.

    3: Write to the input select register, like IOMUXC_XBAR_INOUT17_SELECT_INPUT

    4: Then you'd call xbar_connect(), or just write directly to the XBAR register. But I can tell you (and you can see in the code comments) that 8 bit writes do not work to XBAR registers, so you must do 16 bit read-modify-write to set the XBAR connection you want.

    Hopefully these 4 steps will get the signal connected to the encoder. Then of course you'll need to configure it. More complicated registers to figure out.....
    Last edited by PaulStoffregen; Today at 01:31 PM.

  23. #1073
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,201
    Quote Originally Posted by Frank B View Post
    Softwareserial:
    Code:
    "C:\\Arduino\\hardware\\teensy/../tools/arm8/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1052__ -DTEENSYDUINO=146 -DARDUINO=10808 -DF_CPU=396000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-Ic:\\temp\\arduino_build_958717/pch" "-IC:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SoftwareSerial" "C:\\Arduino\\hardware\\teensy\\avr\\libraries\\SoftwareSerial\\SoftwareSerial.cpp" -o "c:\\temp\\arduino_build_958717\\libraries\\SoftwareSerial\\SoftwareSerial.cpp.o"
    C:\Arduino\hardware\teensy\avr\libraries\SoftwareSerial\SoftwareSerial.cpp:260:2: error: #error This version of SoftwareSerial supports only 20, 16 and 8MHz processors
     #error This version of SoftwareSerial supports only 20, 16 and 8MHz processors
      ^~~~~
    Think I got it working - can someone verify for me. Here are the files new files:
    SoftwareSerial.zip

    Thanks

    UPDATE: Nevermind - not working tested on pins 8/9 and 10/11 but if someone wants to double check. Not sure what pins are going to be allowed

Posting Permissions

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