DSTT INTEL 28F160B3T

[zanetheinsane]

I've got a DSTT INTEL 28F160B3T which is listed as Unknown datasheets but SHOULD BE "supported" Flashchip IDs

DSTT flash checker comes back as "Good". NTRboot flasher only comes back as "Flashcart setup failed".

This is using bootstrap-1.3-ntr and ntrboot_flasher v0.2.0

[handsomematt]

https://github.com/kitling/flashcart_core/issues/56

The latest release isn't the current master, wait for a full release or compile from source.

[zanetheinsane]

Understood, will do and will report back if successful.

[zanetheinsane]

Compiled from current source with similar results. Will wait for a new release version and try again.

[zanetheinsane]

Referencing page 34 of http://pdf1.alldatasheet.com/datasheet-pdf/view/102443/INTEL/GT28F160B3T110.html

It looks like the GT and TE prefixes only denote solder type. The rest of the part number is defined as 28F = Intel Flash 160 = x16 (16 Mbit) B3 = Smart 3 Advanced Boot Block T = Top Blocking

With memory blocks defined starting at page 40.

I was also able to find a configuration file for another flashing program at: https://www.dts-insight.co.jp/support/_lib_tpl/6_flash_memory/numonyx/28F160B3T.frd which defines the sectors, if that information is useful.

I would be willing to recompile and test an entry for 0x9089 in dstt.cpp (with the assumed risk of bricking) if you think any of this information is valid.

[kitlith]

you may need to update the flashcart_core submodule in order to compile with the changes you're looking for.

Try git submodule update --remote, and then recompile.

[zanetheinsane]

I see the new changes to dstt.cpp and recompile was successful.

On testing, “Dump Flash” completes successfully. "Inject Ntrboot -> retail unit ntrboot" gets to the "Reading..." step and hangs at 99%, requiring a long-press on the power-button to recover. It doesn't appear to have affected the normal functionality of the DSTT.

[zanetheinsane]

I did note a new file: r4sdhc_dualcore.cpp

This file produced "not delcared in scope" errors for memcpy(), enc, and BIT()

I did not include this file in my test build.

[kitlith]

I changed the erase specification given the new information, would you like to give it a try now? You'll need to update flashcart_core again.

[kingmercian]

@kitling Just tried the updated flashcart_core and unfortunately still the same issue where it gets stuck when reading at 99%.

[zanetheinsane]

Same for 0x9089 . Gets to "Reading" at 99%.

[kitlith]

Try with this: [old build removed]

It should generate a debug.log in the ntrboot folder. Send that back to us so we can take a look at it.

[kingmercian]

This build does not seem to leave any debug.log within ~/ntrboot it may be because it hangs while reading from the flashcart (I had also dumped and restored flash - still no log). In case you ask the flashcore rev == 111d.

[kitlith]

so, let me get this straight. Dumping works. Restoring works. Only injection has any issues.

I'm thinking there's some sort of state transition failure going on. I don't know.

... and I just realized why a log wasn't geneated. I gated it with a #define. And then didn't define it.

[kitlith]

Try the latest commits, and if they don't work (I don't think so, but...), try this build: https://up1.secretalgorithm.com/#aQTzfvI1bN9jOzwVH0_GWA

This time I actually enabled the logging. >_>

[zanetheinsane]

Latest commit compiles and DSTT is selectable (for 0x9089) but still hangs at 99%.

The debug version posted above gives an arm9 crash when selecting DSTT. crash_dump_00000001.zip

[kitlith]

... AKA, I dun goofed somewhere with my logging code. sigh

[kingmercian]

Precompiled debug build == Hangs on selected DSTT flashcart (I do not get an arm9 crash as @zanetheinsane is having) something is awry.

flashcart_core -b master == stuck reading at 99%

flashcart_core -b big_refactor == compilation error as follows:

dstt.o: In function `DSTT::rawRead(unsigned long, unsigned long, unsigned char*)':
/Users/kingmercian/3ds/ntrboot_flasher/flashcart_core/devices/dstt.cpp:226: undefined reference to `unsigned long Flashcart::read_wrapper<DSTT, &DSTT::readWord, 4ul>(unsigned long, unsigned long, unsigned char*)'

I believe you are correct about the transition state possible causing it while switching from reading as we are able to dump and restore flash, it's just injectNtrBoot that it hangs on.