Search results

How many T3.2s do you need? I have a bunch from an old project I could throw up on eBay or something.

Yes, it's a limitation of the driver you're using. Something like a SmartMatrix can display thousands of colors with a Teensy: https://github.com/pixelmatix/SmartMatrix

I think they'll probably be closer to $20 to cover the MKL02 and Paul's royalties. Hopefully we'll know soon.

NXP has development tools for the 1062 used in the Teensy 4 that includes FreeRTOS support, but I don't know how much work it would be to get it moved over. https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-software-development-kit-sdk:MCUXpresso-SDK

I have had zero issues with TeensyLoader through PlatformIO.

@mjs513 Obviously untested, but I think it would be a lot easier to debug with a double loop - here's my guess at what you're doing. DMAMEM unsigned char image[324*244]; void send_image() { uint32_t imagesize, fbc; imagesize = (320 * 240 * 2); memset(frameBuffer, 0...

'0' and 48 and 0x30 are all the same thing - the Ascii code for the zero character.

There's a built-in tool labelled "Serial Monitor" that you can access from the tool bar at the bottom of the window, the icon looks kind of like an (American) electrical plug.

That seems like a problem - MISO should be CIPO, and MOSI COPI, right? Since Master -> Controller and Slave -> Peripheral in the new naming scheme.

Looks like all the pins for an 8-bit LCD interface are there (GPIO_B0_0 - GPIO_B0_11)

There are SWD_CLK and SWD_IO pins listed on the MicroMod MKL02 which go to test points, so maybe there's some hope there?

I'd be interested in beta testing, working with a custom carrier currently using the 4.1 that does a lot of serial IO and heavy CPU. However I just ordered the MicroMod support stuff from Sparkfun so it might not make sense depending on timing, especially if you've already allocated the ones you...

Low volume commercial products.

It might be too much of a compromise to make sense, but it seems possible to do a form factor that includes both the through hole breadboard headers on the sides and the MicroMod M.2 connector on one end.

The replacement chip is the "B" version from the previous few messages. Should work identically for our purposes but hasn't been verified at this point.

I'd also really like to see a MicroMod version. There would probably be enough real estate to include at least one of the memory pads from the 4.1.

Hasn't JTAG always been a business decision rather than a technical one? I've always thought it was only missing to help protect PJRC from clone vendors.

This very good blog post, which describes the internal logic of the 2812 including the "cheat" it uses for reading is a good place to start.

My takeaway from the 1060 manual was that the built-in PXP stuff wasn't actually useful unless you were directly driving the output on the LCD interface.

Stay safe everyone! It's "only" in the 200s here in western WA and even that is miserable. A good time to stay indoors if you can and work on those Teensy projects.

Just as a reference, on my MacBook (Pro 2016 - Mojave) if I do the 15 second restore it will be seen by Teensyduino in "HID Mode" but not as a USB device for Teensy Loader.

I'm suggesting that the second board in the 5 series would be in a new format, the first would still be in the traditional Teensy layout.

I really think that rather than the breadboard and longer breadboard form factor it's time to move to a breadboard and module release where the "5.1" equivalent is available on a castellated module rather than the breadboard friendly form factor. It allows bringing out more pins and is more...

Thanks for the responses! This version does appear to be giving plausible results as long as it's called prior to switching to 4bit transfers. I would not be at all surprised if some of the flags are still wrong. You were correct that the sector read had the wait after the data read. static...

So far I haven't had any luck getting anything but SDHC_RESULT_ERROR from CMD6. Some of the flags are just guesses based on the other commands, but I've tried all the variations I can think of. EDIT: I can get a OK response if I call this earlier in SDHC_CardInit() before changing to 4 bit data...

Is there a technical reason other than too few hours in the day that high speed mode hasn't been implemented in NXP_SDHC per this TODO note? I might try it, but if there's a known issue I won't bother. https://github.com/PaulStoffregen/SD/blob/master/utility/NXP_SDHC.cpp#L565

I'm moving back around to this on my current project and would be happy to contribute however I can as soon as there is some sort of marching orders. My personal goals are some level of compatibility between SD and NAND storage and a non-blocking read call.

Glad you got it working. I hope that as soon as the upcoming "generic File" stuff from Paul is finalized there will be a push for a more unified library for this stuff.

It looks like some of your constants are wrong as well. The registers should be A0, B0, C0 rather than 0A, 0B, 0C

I'm pretty sure you should be in SPI mode 0 the whole time rather than switching to mode 3.

Q(5) = Green Package (Lead-free, RoHS Compliant, Halogen-free (TBBA), Antimony-Oxide-free Sb2O3) with QE = 1 (fixed) in Status register-2. Backward compatible to FV family. M(6) = Green Package (Lead-free, RoHS Compliant, Halogen-free (TBBA), Antimony-Oxide-free Sb2O3) with QE = 0 (programmable)...

Right click on the .hex file in VSCode and select "Reveal in Finder"

After my patented "see what's on GitHub" search process I also thought dhara looked interesting, but whatever Paul is planning in terms of the new file abstraction might make a big difference in the best way to approach a higher level NAND API.

This is how I understand it. Any of this could be wrong. On the 1062 side CAS is where the 1062 divides a 32 bit address into the column and the page. The value in the LUT defines how many bits are actually sent, so if it's larger than CAS for a CADDR_SDR command (or larger than 32 - CAS for a...

If CAS isn't set, isn't it going to fail on any address with bit 12 set because those aren't real pages, but ECC sections? What issue were you trying to fix with that change?

Unfortunately that's not how NAND flash works, you can clear bits from a 1 to 0 but not the other way, so you can't erase a single page, you have to use the block erase command.

Unfortunately erase is per block, so it has to be separate from the write. setTimeout() is treating timeoutAt as a time, but waitForReady() is using it as if it was a period.

There's a bug I forgot to mention in setTimeout / waitForReady. It should probably be updated to just use an ElapsedMillis object and a numerical timeout value? Anyway the version in GitHub is wrong.

Excellent. Hopefully that will be enough of a working baseline to build up the missing features.

Try erasing sector 0 (or the entire chip) first. The addressing was changed so it's unclear what would have been on there previously.

I thought it was broken when I tried to set Column bits to 11 but I think I had just messed up the ECC during my previous testing. So I think that will work with the caveat that we'll have to do some special case code if we ever want to directly interact with the on chip ECC storage. Non-Zero...

Hmm, the column address is 12 bits, but it only "needs" 11 (maybe so you can access the ECC data?) But that means there's no continuous addresses.

Staying with a single page write to try and tackle one issue at a time. There's something address related to the odd/even pages. uint8_t page = 2; Serial.println("Non-Zero Test Write"); for (uint16_t i = 0; i < 2048; i++) buffer[i] = page; myNAND.writeBytes(2048 * page, buffer, 16)...

There were some problems with the timeouts in the read stuff, so the page wouldn't always make it to the buffer. I think this is another incremental improvement. I seem to be able to write and erase, and have stuff persist over a power cycle, but I thought I had a fix before...

This code is definitely loading into the buffer because when I use it for read() I can get back the test sequence that's somewhere on my chip. Who knows where that data might be, but it's saved and this code is putting it into the buffer. FLEXSPI2_LUT48 = LUT0(CMD_SDR, PINS1, PAGE_DATA_READ)...

I don't have the 1050 manual, but from the link you posted on page 1 it appears to be using 24bit page address with no dummy bits in the sample code LUT.

Well great, apparently some random thing I did during testing was what managed to get the ProgramExecute working because I 100% for sure have the data stored somewhere on my chip.

Try address 0 instead of 3000, as I said I'm not at all confident about the page addresses, but I currently boot with no write code enabled and get the test sequence...

Made a tiny bit of progress. It seems that the operand on the commands using the page address is wrong. It was originally 0x20. I thought it should be 0x10, since it's only two bytes, but that doesn't work either. With 0x18 I do get stuff actually written to and read from the chip through a...

It isn't currently formatting, but the chip is initially formatted, and we don't appear to be disturbing that yet. As far as I can tell nothing is actually making it from the on chip buffer to the NAND storage on the flash, although the copy from the Teensy to the buffer is working, which is why...