Teensy 4.0 First Beta Test

Status
Not open for further replies.
Michael,
Deviating slightly, let me turn the problem around.
If I wanted, as it is with T3, all program code and constants in Flash and only non-constant data in RAM, how should I instruct compiler and linker?
Reason: Contrary to suggested RAM based execution, I would like to use RAM for data buffer.

For normal data, just use the const keyword. I.e.
Code:
static const char array[] = "test";

Note however, due to the inside out way C/C++ data declarations are done, the const and volatile go to the results of a function or what a pointer points to, and not the base item. I.e. this means ptr1 itself is in read/write memory, but the compiler will not let you write to the address the pointer points to (i.e. data1).
Code:
static const int data1[] = { 1, 2, 3, 4 };
static const int *ptr1 = &data1[0];

This means ptr2 itself can not be modified, but you can modify what the pointer points to:
Code:
static int data2[] = { 1, 2, 3, 4 };
static int *const ptr2 = &data2[0];

This means ptr3 itself cannot be modified, and you can't modify what the pointer points to:
Code:
static const int data3[] = { 1, 2, 3, 4 };
static const int *const ptr3 = &data3[0];

This fragment shows what can be done. The functions that are commented out are illegal, and the compiler will flag them as an error:
Code:
static const int data1[] = { 1, 2, 3, 4 };
static const int *ptr1 = &data1[0];

void set_ptr1 (int n)
{
  ptr1 = &data1[n];
}

// void mod_ptr1 (void)
// {
//   *ptr1 = 10;
// }

const int *ret_ptr1 (void)
{
  return ptr1;
}

// =======================================

static int data2[] = { 1, 2, 3, 4 };
static int *const ptr2 = &data2[0];

// void set_ptr2 (int n)
// {
//   ptr2 = &data2[n];
// }

void mod_ptr2 (void)
{
  *ptr2 = 10;
}

int *ret_ptr2 (void)
{
  return ptr2;
}

// ======================================

static const int data3[] = { 1, 2, 3, 4 };
static const int *const ptr3 = &data3[0];

// void set_ptr3 (int n)
// {
//   ptr3 = &data3[n];
// }

// void mod_ptr3 (void)
// {
//   *ptr3 = 10;
// }

const int *ret_ptr3 (void)
{
  return ptr3;
}

This is all for the standard way things are set up by the compiler and linker. Obviously Paul may have made modifications of how things are done in the T4. While I'm on the beta list, I didn't have time to fiddle with the early beta types, and told Paul/Robin to put me on the later list. So I don't have a T4 at this point.
 
I wrote a little tool (imxrt-size) that displays more useful info than Arduino.

For example:
Code:
ITCM : 16544 B  (16.16 KB)
DTCM : 17088 B  (16.69 KB)
OCRAM: 3904 B   (3.81 KB)
Flash: 27360 B  (26.72 KB)

Works for me Frank. Incorporated into Compile.cmd like this with hardcoded path to imxrt-size.exe:
if "%errorlevel%"=="0" "%arduino%\hardware\tools\arm\bin\arm-none-eabi-gcc-nm.exe" "%temp1%\%sketchname%.ino.elf" -n | "T:\Programs\TSet\imxrt-size.exe"

"T:\\arduino-1.8.8T4_146\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\\\arduino_build_DebugMin_tt.ino/DebugMin_tt.ino.elf"
Sketch uses 40224 bytes (2%) of program storage space. Maximum is 1572864 bytes.
Global variables use 37568 bytes (14%) of dynamic memory, leaving 224576 bytes for local variables. Maximum is 262144 bytes.
upload@1000020-Teensy Uploading to board '1000020-Teensy' (Teensy 4.0)
upload@1000020-Teensy Firmware: DebugMin_tt.ino.teensy4b.hex
upload@1000020-Teensy Flash usage: 45 kiB (2.9%)
upload@1000020-Teensy Uploading...
upload@1000020-Teensy Sending reset command
ITCM : 32416 B (31.66 KB)
DTCM : 37568 B (36.69 KB)
OCRAM: 0 B (0.00 KB)
Flash: 45712 B (44.64 KB)

Frank: For reference is that by any chance: "Instruction"TCM and "Data"TCM

Mike: Is there a posted copy of the software USB_HOST libs as you have them? Just to glance to see what debug_tt might do to replace the code under the #ifdef DEBUG_xx
 
@KurtE - if you are going to go down the route of porting over uhs2 controllers, let me know and I will stop working on this.

I say go for it. I have not done much here in a year, as very few people showed interest... So this will hopefully inspire some of us to get the BT stuff usable enough, that we can then get it merged into the mainline...
 
@Tim, I hope we can find a way to add it to platform.txt?
Have not testest it extensive, I hope the numbers are correct :) They differ from Arduino because Arduino just displays wrong numbers..
Sourcecode added to Post 1624

 
Last edited:
I say go for it. I have not done much here in a year, as very few people showed interest... So this will hopefully inspire some of us to get the BT stuff usable enough, that we can then get it merged into the mainline...

@KurtE
Going to play around some more with joystick - now its the challenge :) Besides it giving me some familiarity with USH_Host. Like you said don't know how much interest there is in BT but I like using my PS4 controller for my robotics projects.
 
@Frank, Adding it to standard build in platform.txt would be good if there is no better way to know. Given the larger set of memory pools it will take knowing what is were to optimize the system - or even get it to work when things get 'tight'.
Did you once post a RunTime memory dump ? It would be too late to display that if something goes OverFull - but it might be nice to have that if at run time we could also see the dynamic RAM usage.

Did you see my question if the two TCM's are Instruction and Data?
 
Hi Tim, yes, ITCM is the instruction-RAM, DTCM is the data-RAM. I think ITCM can hold data, too.. but we don't use this, at the moment. OCRAM holds "DMAMEM" and the heap.

Edit: It would be a pity to waste the ITCM for code that runs only once, like initialization-code.. that's why I want to have a way to NOT copy such code to the ITCM.
PROGMEM works, but then you can't use PROGMEM in the same file for data.. (See my question @MichaelMeissner)
 
Thanks Frank, will make reading easier knowing that for sure.

RE: PROGMEM

Paul uses .startup for code used early in startup.c like:
Code:
__attribute__((section(".startup"), optimize("no-tree-loop-distribute-patterns")))
void ResetHandler(void)

This sketch puts int pmABC into PROGMEM, and the testABC() func in .startup
Code:
PROGMEM int pmABC = 100;
__attribute__((section(".startup")))
void testABC() {
  // pmABC*=2;
  for ( int ii=0; ii<pmABC; ii+=10 )
    SERIAL_tt.printf("  pmABC==%u", pmABC );
}

And it works, unless you want to FAULT and try to write to pmABC.

Like Frank's post 1592 shows in file :: T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\imxrt.ld::
Code:
SECTIONS
{
	[B].text.progmem[/B] : {
		KEEP(*(.flashconfig))
		FILL(0xFF)
		. = ORIGIN(FLASH) + 0x1000;
		KEEP(*(.ivt))
		KEEP(*(.bootdata))
		KEEP(*(.vectors))
[B]		KEEP(*(.startup))
		*(.progmem*)[/B]
                . = ALIGN(4);
                KEEP(*(.init))
                __preinit_array_start = .;
                KEEP (*(.preinit_array))
                __preinit_array_end = .;
                __init_array_start = .;
                KEEP (*(.init_array))
                __init_array_end = .;
		. = ALIGN(16);
	} > FLASH

So both of those end up in FLASH without the compiler complaining because it is the Linker that resolves that.

PROGMEM isn't the clearest here saying Memory into Program area in T4 context … but that is the history.

So having a second define like: #define PROGMEM __attribute__((section(".progmem")))

Probably a better or worse name - but on ARM/T_3.x or AVR it could just default to the current PROGMEM?
#define FLASHPROG __attribute__((section(".startup")))
 
@KurtE and @defragster

Reinstalled Bluetooth WIP lib + remembered to update to Beta9. Seems to be working now but not taking chances and try to cause a fault. Still want to figure things out with why the problems. But been playing around with the sketch for PS4 and joystick. Here's a sample of the new data output - one function for getAxisPS4.

Code:
LX: 132, LY: 124, RX: 129, RY: 129 
L-Trig: 0, R-Trig: 0, Trig-Button: 0 
Buttons: 8, PS: 0

LX: 133, LY: 124, RX: 130, RY: 129 
L-Trig: 0, R-Trig: 0, Trig-Button: 0 
Buttons: 8, PS: 0

Looking at the PS3, XBOX360, they are both wireless but at 2.4Ghz - only the PS4 so far as I can see is still Bluetooth.

KurtE - is it possible for you to gin up a function for testing in a sketch if the BT is connected to a controller? I am tired now. Going to post what I have so far on my WIP page.

EDIT: Forgot, I also posted a JoystickBT example, with the modified getAxis
 
@MichaelMeissner

Michael, what do you think:
Code:
#define _STRINGIFY(a) #a
#define ___in_section(a, b) __attribute__((section( "." _STRINGIFY(a) "_" _STRINGIFY(b) )))
#define __in_section(a, b) ___in_section(a, b)
#define __in_section_unique(seg) ___in_section(seg, __COUNTER__)

#undef PROGMEM
#define PROGMEM __in_section_unique(progmem)
[COLOR=#ffa500]// ^^^^ this should go into pgmspace.h[/COLOR]

PROGMEM const volatile int foo = 5;
PROGMEM __attribute__((noinline)) void testfunction() {Serial.println("HI");}
PROGMEM void setup() {testfunction();Serial.println(foo);}

void loop() {}

Would have defining PROGMEM this way any negative effects?

It is unique now, using __COUNTER__ so the linker can remove single "PROGMEM" sections.
AND: No error message :)

Edit: It creates sections like ".progmem_0", ".progmem_1" ... ".progmem_n" . In the ld-file we have "*(.progmem*)"
I found this after a lot of googling - I thought, we just need to have unique names - then I saw __COUNTER__ and found this way.
__COUNTER__ seems to be supported not only by GCC. Clang, and even Microsoft supports it (I've read)

Edit: A PR would look like this:
https://github.com/PaulStoffregen/cores/compare/master...FrankBoesing:ProgmemFix
 
Last edited:
USBHost_BT_PS4

@KurtE: Added another function for getOnChange to test if all the data was changed but.. need to expand that so can only print the axis or button that actually changed.

Also trying to implement the setRumble function for PS4 but need some help - can you tell me what the process is to send command back to the PS4. Not obvious with BT. Not sure really need the available since I got the onchange function operational but if there was a way to tell the user BT connected.
 
Looking at the PS3, XBOX360, they are both wireless but at 2.4Ghz - only the PS4 so far as I can see is still Bluetooth.
The PS3 also used BT, but did not fully follow standards... So for a long time, you would run some modified version of code on the Bluetooth to work with it. Later in Bluez 5 support will added directly into the driver...

https://help.ubuntu.com/community/Sixaxis

KurtE - is it possible for you to gin up a function for testing in a sketch if the BT is connected to a controller? I am tired now. Going to post what I have so far on my WIP page.

EDIT: Forgot, I also posted a JoystickBT example, with the modified getAxis

Hi mike not sure what you are asking here? I think you are asking to be able to ask the BT object if some thing is connected? Or do you want the Joystick object to shown as connected? Which I think is currently a bug that it does not.

We may end up needing both, but I think we need a few changes to make the Joystick object show as a connected object...

That is: in joystick.cpp the function: JoystickController::claim_bluetooth(BluetoothController *driver, uint32_t bluetooth_class)
probably need to add: connected_ = true; // remember that hardware is actually connected...

Also void JoystickController::release_bluetooth() should probably set this to false.

And in usbhost_t36.h in the JoystickController class need to change the operator bool() from:
operator bool() { return (((device != nullptr) || (mydevice != nullptr)) && connected_); } // override as in both USBDriver and in USBHIDInput
to probably:
operator bool() { return (((device != nullptr) || (mydevice != nullptr) || (btdevice != nullptr)) && connected_); } // override as in both USBDriver and in USBHIDInput


I will make these changes and make sure things still compile... (At least the parts about joystick in use...).

And maybe order a new DS4 controller to try it out...

EDIT: pushed up changes mentioned

EDIT2: Ordered new PS4 controller, should get here Wed... But depending on snow storms...
 
Last edited:
@KurtE

Thanks for the implementing those changes. One of the things that I was just looking at was the setRumble/setLEDs functions. Think I found a solution, but not sure how to grab the HCI Handle for sendL2CapCommand function you have in Bluetooth.cpp (think this is the right function to use. Right now the function is laid out as follows:
Code:
bool JoystickController::setRumblePS4(uint8_t lValue, uint8_t rValue, uint8_t timeout)
{
	// Need to know which joystick we are on.  Start off with XBox support - maybe need to add some enum value for the known
	// joystick types. 
	rumble_lValue_ = lValue; 
	rumble_rValue_ = rValue;
	rumble_timeout_ = timeout;

	uint8_t packet[32];
    memset(packet, 0, sizeof(packet));

    packet[0] = 0x05; // Report ID
    packet[1]= 0xFF;

    packet[4] = rumble_lValue_; // Small Rumble
    packet[5] = rumble_rValue_; // Big rumble
    packet[6] = leds_[0]; // RGB value 
    packet[7] = leds_[1]; 
    packet[8] = leds_[2];
    // 9, 10 flash ON, OFF times in 100ths of sedond?  2.5 seconds = 255
    Serial.printf("Joystick update Rumble/LEDs");
	//(uint16_t handle
	BluetoothController::sendL2CapCommand(handle , packet, sizeof(packet));  // handle I think is HCI handle?
	
	return true;
}
Not pretty coding but.....

EDIT2: Ordered new PS4 controller, should get here Wed... But depending on snow storms...
Getting lucky in NY no snow - next storms are suppose to be snow/rain/sleet - just a mess.


EDIT:
The PS3 also used BT, but did not fully follow standards... So for a long time, you would run some modified version of code on the Bluetooth to work with it. Later in Bluez 5 support will added directly into the driver...

https://help.ubuntu.com/community/Sixaxis
Is it worth picking up a PS3 controller, can get two from amazon, for 25 delivered today - https://www.amazon.com/Controller-W...tooth+controller&refinements=p_96:10155283011, ?
 
Last edited:
@mjs513 - Need to look more at the back channel stuff. I noticed in the keyboard code for updating LEDS, that comment is there needing to setup back channel...

Maybe need a public function either on bluetooth object that can be used to grab the internal device_connection_handler_
Like the sendPacket used for the USB mode...

And/Or needs to be member on the ...

As for PS3... This is what a lot of Robot kits used a few years ago, that connected up to RPI or similar boards, so would be nice to make work...

I may also try to spend some time maybe getting mouse to work... Now do have a BT mouse...

As for snow (yes I know off topic). We maybe get snow once or so a year, that usually does not last long. Got down to under 20 degrees last night) So lots of bad drivers... This last week we had two snow storms and maybe now two more coming this week... And as of yesterday my driveway (maybe a couple of hundred yards long) looked like:
IMG_0687.jpg

Edit: probably should have rotated picture :D but looks like that if you are driving too fast

Then we go down a half mile dirt road... And then 8 or so miles to town... So we usually just wait it out... But may go into town this morning as getting low on Sugar.....

Hummingbirds...

IMG_0666-(002).jpg
 
@mjs513 - Need to look more at the back channel stuff. I noticed in the keyboard code for updating LEDS, that comment is there needing to setup back channel...

Maybe need a public function either on bluetooth object that can be used to grab the internal device_connection_handler_
Like the sendPacket used for the USB mode...

And/Or needs to be member on the ...

As for PS3... This is what a lot of Robot kits used a few years ago, that connected up to RPI or similar boards, so would be nice to make work...

I may also try to spend some time maybe getting mouse to work... Now do have a BT mouse...
PS3 think will be easier that PS4 once I get PS4 finished. Yes I think I agree we need something like sendpacket except for Bluetooth but I think the sendl2command would work once we get a public link to the what ever is the correct handle.

I just ordered a PS3 from amazon so once PS4 is done the I can work on the PS3.

I know about shopping, just got back. Around here people go shopping and stock up like they aren't going to be able to get around the house for days and days. Usually everything is clear the next around here, unless we get 1 foot or more of snow. Which happens occasionally.

EDIT: I think this is the handle that we need: device_connection_handle_ but having c++ trouble getting it over to joystick.cpp
 
Last edited:
@mjs513 - I think that may be the right handle.

What I was thinking of doing, maybe you can beat me to it, was maybe add a function like:
sendL2CapCommand to the BTHIDINput class and make sure that this class is a friend of BluetoothController class.
Then maybe move the device_connection_handle_ member to be protected (not private). And then have the method in BTIDInput call of to the one in BluettothController class with the right handle...
Not sure if that makes sense...

If you get something to work, would be great if you did a PR or the like...

As for what I should do next... Not sure maybe play with mouse... Or once back channel is working maybe see about adding it to keyboard and see if it works...

Or we also just got back from town and I picked up my 3.5" display from the Mailbox in town... So maybe play with trying to get that to work...

@tonton81 - Yep you get a lot more of the stuff then we do, so probably everyone around you is used to it... Here it is infrequent enough that as @mjs513 mentioned, everyone buys out the store...
We did make it into town and picked up another 15 pounds of sugar for the birds, plus more dog treats and ...
 
@mjs513 - I think that may be the right handle.

What I was thinking of doing, maybe you can beat me to it, was maybe add a function like:
sendL2CapCommand to the BTHIDINput class and make sure that this class is a friend of BluetoothController class.
Then maybe move the device_connection_handle_ member to be protected (not private). And then have the method in BTIDInput call of to the one in BluettothController class with the right handle...
Not sure if that makes sense...

If you get something to work, would be great if you did a PR or the like...

As for what I should do next... Not sure maybe play with mouse... Or once back channel is working maybe see about adding it to keyboard and see if it works...

Or we also just got back from town and I picked up my 3.5" display from the Mailbox in town... So maybe play with trying to get that to work...

@tonton81 - Yep you get a lot more of the stuff then we do, so probably everyone around you is used to it... Here it is infrequent enough that as @mjs513 mentioned, everyone buys out the store...
We did make it into town and picked up another 15 pounds of sugar for the birds, plus more dog treats and ...

Glad you got what you needed at the store before everything sold out :)

I was trying to work from Bluetoothcontroller class and yes I did move device_connection_handle_ to private. But keep getting a c++ error "error: cannot call member function 'uint16_t BluetoothController::getDeviceHandle()' without object". Will try your approach and go from BTIDInput class. Have a couple of things to do now so will get back to it later.
 
Thought I would pickup something similar to play with... SO ordered this one on Ebay: https://www.ebay.com/itm/392220881268

Shipped today, ETA Monday...

Arrived early, and I made it into town this morning...

So looking at the back of this board it appears like it was configured for 3 wire SPI and Capacitive touch... Wondering if I should try to reconfigure to 4 wire SPI?

Probably won't touch the touch stuff at first, but would be nice to get something displayed

EDIT: Should mention I don't believe the 40 pin connector is setup for RPI... It has a male connector... I think it is to allow for multiple of different ways to interface this display.
1-GND, 2-VCC,
3-20 DB0-DB18 (18 bit parallel mode)
21 reset

SPI:
23 CS
24 SCL
25 DC
27 SDI
28 SDO

29 back light control
30,31 SCL/SDA - I2C for Capacitive touch
32-35 (SDO, SCL, SDI) for other stuff
35 CS for SD
36 CS for font(none installed)
37 CS for Flash (none installed)
...
 
Last edited:
@Tim, I hope we can find a way to add it to platform.txt?
Have not testest it extensive, I hope the numbers are correct :) They differ from Arduino because Arduino just displays wrong numbers..
Sourcecode added to Post 1624


Tim, I have it working.
Solution for windows: (other OSes the same.. subsitute the paths and e.g. use ".linux" instead ".windows")
Code:
recipe.hooks.postbuild.4.pattern.windows=cmd /c "{runtime.hardware.path}\..\tools\arm\bin\arm-none-eabi-gcc-nm -n {build.path}\{build.project_name}.elf | {runtime.hardware.path}\..\tools\imxrt-size"
(copy imxrt-size to the tools directory)

Output looks like this:
Code:
C:\\Arduino\\hardware\\teensy/../tools/teensy_post_compile" -file=sketch_feb10a.ino "-path=c:\\temp\\arduino_build_965921" "-tools=C:\\Arduino\\hardware\\teensy/../tools/" -board=TEENSY40
cmd /c "C:\\Arduino\\hardware\\teensy\\..\\tools\\arm\\bin\\arm-none-eabi-gcc-nm -n c:\\temp\\arduino_build_965921\\sketch_feb10a.ino.elf | C:\\Arduino\\hardware\\teensy\\..\\tools\\imxrt-size"
[COLOR=#0000ff]ITCM :   5056 B    ( 3.86% of  128 KB)
DTCM :   8896 B    ( 6.79% of  128 KB)
OCRAM:      0 B    ( 0.00% of  256 KB)
Flash:  11984 B    ( 0.76% of 1536 KB)[/COLOR]
"C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "c:\\temp\\arduino_build_965921/sketch_feb10a.ino.elf"
Der Sketch verwendet 6496 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 1572864 Bytes.
Globale Variablen verwenden 8896 Bytes (3%) des dynamischen Speichers, 253248 Bytes für lokale Variablen verbleiben. Das Maximum sind 262144 Bytes.

If it is no Teensy4, there is no additional output.
There was a minor bug, fixed version here:
 

Attachments

  • imxrt-size.zip
    27.5 KB · Views: 66
  • imxrt-size.c
    1.6 KB · Views: 76
Last edited:
@mjs513 - I did a hack to hopefully allow you to send off l2cap... I pushed up something that compiled... Probably completely wrong, but maybe along the right path?
 
@mjs513 - I did a hack to hopefully allow you to send off l2cap... I pushed up something that compiled... Probably completely wrong, but maybe along the right path?

Was busy most of the day and just getting ready to read up on friend classes - never really used them before - so this is a learning experience. Sundays are usually family day.


EDIT: Just took a look and it looks good. Was making it more complicated than it had to be
 
Tim, I have it working.
Solution for windows: (other OSes the same.. subsitute the paths and e.g. use ".linux" instead ".windows")
...

Indeed Frank - that works well! With the EXE in tools and used the postbuild.4 line and the allocations were presented in the build window! [ Both the IDE and SublimeText w/Compile.cmd ]

Here is the version from the IDE - notice the odd line in BOLD - don't recall seeing those characters in the expanded and unprinted way before? [they are printed ok in SublimeText window]
cmd /c "T:\\arduino-1.8.8T4_146\\hardware\\teensy\\..\\tools\\arm\\bin\\arm-none-eabi-gcc-nm -n T:\\TEMP\\arduino_build_440856\\DebugMin_tt.ino.elf | T:\\arduino-1.8.8T4_146\\hardware\\teensy\\..\\tools\\imxrt-size"
ITCM : 32416 B (31.66 KB)
DTCM : 37568 B (36.69 KB)
OCRAM: 0 B (0.00 KB)
Flash: 45712 B (44.64 KB)
===info ||| Using library {0} in folder: {1} {2} ||| [debug_tt t%3A%5Ctcode%5Clibraries%5Cdebug_tt %28legacy%29]
"T:\\arduino-1.8.8T4_146\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_440856/DebugMin_tt.ino.elf"
Sketch uses 40224 bytes (2%) of program storage space. Maximum is 1572864 bytes.
Global variables use 37568 bytes (14%) of dynamic memory, leaving 224576 bytes for local variables. Maximum is 262144 bytes.
That line is printed normally in SublimeText like this:
Using library debug_tt in folder: T:\tCode\libraries\debug_tt (legacy)
<EDIT> Frank - removing the postbuild.4 line returns the IDE display to match that in SublimeText - the odd added text and the %# chars display is corrected

Question about the imxrt.ld script, the values of size [ will change of course when 1052 moves to 1062 ] - but regarding the SPLIT between TCM I and D:
>> Is this fixed elsewhere in the processor and setup - or is there a way this 50:50 split between ITCM and DTCM can be changed based on application?
ITCM (rwx): ORIGIN = 0x00000000, LENGTH = 128K
DTCM (rwx): ORIGIN = 0x20000000, LENGTH = 128K
 
Tim, not sure where that bold line comes from - It's not displayed on my system. (Please update imxrt-size, new version attached to previous post)
ITCM/DTCM - not sure.. just searched the manual and it states:
• RAM size of ITCM, DTCM and OCRAM can be configured from 0 to full RAM
Array size separately
• Step of the RAM size partitioning for ITCM, DTCM and OCRAM is (Total
RAM SIZE)/16

Edit: Nope.. i get the bold line too, now. Seems to be the output of imxrt-size(?) I don't know how to solve that. Maybe Paul knows.
 
Status
Not open for further replies.
Back
Top