Bootloader n120 Remake

[boreal light]

Yes, I just said the difference between n0110 and n0120

[jovial torrent]

ik for the usb port change

[boreal light]

This component isn't been soldered on your board？

[jovial torrent]

on any board

there is just no U3 in an n120

it's just there

xD

[boreal light]

Maybe in old version it has been soldered

[jovial torrent]

ah

[zealous tree]

This is N0120EX

[jovial torrent]

the one with u3?

what's the difference

[boreal light]

Maybe EX has deleted the function of SBU signals

[jovial torrent]

isn't it quite the opposite?

[boreal light]

My fault

[zealous tree]

I don't know but on N0115 there is also an empty slot for U3

[boreal light]

Yes, it's also made for SBU signals

But referring from network, these signals are for especial usage, such as SWD, uart, audio, HDMI, etc

I don't know what unique functions n0120ex has

[jovial torrent]

idk, but we'll do without it for now

[boreal light]

Yes, just put them back

[jovial torrent]

yea but i'll not put one back

[boreal light]

There's only one pin left. Could you test if LCD-EXTC is connected to PE2, the first pin of stm32

[jovial torrent]

yea

[boreal light]

Thanks a lot. Now the PCB is complete

[jovial torrent]

yea

[boreal light]

While making the schematic, I figure out the power supply mode: SMPS only mode

This can be configured in CubeMX

[jovial torrent]

so now do you know why it's not working with the mpu activated ?

[boreal light]

I think it is probably the address areas are conflict

Can you show me the configuration below?

[jovial torrent]

ah ik why it was not working

i was trying the last one

but that's not correct

and with this one it's working

we can activate regions but idk what it is

up to 16 regions

[boreal light]

I found an example

[jovial torrent]

just got it

[jovial torrent]

it's hard to place the pins

i need to push the pins else it just disconect

it's swdio or swclk that's the input on the stm32

[boreal light]

Yes, without soldering, it may be hard to place

[boreal light]

swdio is a two way port, swclk is input

[jovial torrent]

ok

[boreal light]

If you connect both stlink and Numworks to computer, you don't need to connect GND with a DuPont line

[jovial torrent]

ah

yea

ah no

i need to connect it

[boreal light]

Maybe your stlink separate USB GND and debug GND

[jovial torrent]

yea

[jovial torrent]

@boreal light Could you please change the language to english in the schematics so it's universal

i'm doing it

[boreal light]

Isn't it English? It's already English in my memory

[jovial torrent]

that wasn't english

[boreal light]

These words are English words

BTW, I asked the LCD's manufacturor, they didn't reply

These manufacturers are somehow 'snobbish' and won't reply unless you're ready to do big business with them.

[jovial torrent]

😢

[jovial torrent]

now yes

[jovial torrent]

so how are we gonna do for the screen

[boreal light]

There is no problem sending common instructions.

Like set whole screen to red, green or blue

Just not send extra commands

[jovial torrent]

what's extra commands

[boreal light]

Adjusting gamma parameters

If not right, that may damage your screen

[jovial torrent]

😦

and what's the difference between the different versions of the screen ?

[jovial torrent]

and are you sure of that or do we just need to wait

[timber tundra]

all the docs relative to the screen is on Numworks Github

N0115/N0120 just need extra care because they use a different gamma config that need to be applied case by case

[boreal light]

So it's fine to refer from a tutorial about st7789v

[timber tundra]

n0110 code should be fine

just don't play too much with the screen, just try to get the ID for now

[boreal light]

While reading the source code of upsilon, I found the chip ID

It is not the common ST7789 ID (0x858552)

[timber tundra]

I'm not sure this is chip id

There is a ton more now

[boreal light]

Regarding to panelIdentifier(), this is the standard method of reading chip ID from st7789

So these are probably customized ID

BTW, there's a simple way to read chip ID from n0120, just soldering wires on uart port, and send 'SCREEN_ID', you'll get the chip id from uart console

[jovial torrent]

so is it possible to get the exact screen model?

[boreal light]

I was working on how to read screen ID, and I succeed in reading n0110

[jovial torrent]

with the screen id (of the n120) can we have the exact model?

[boreal light]

It's 0x4e4101, as written in source code

But this program has some problem on n0120, I'm fixing it

[jovial torrent]

hmm do you have an n120?

[boreal light]

I bought one, and I'm tesing its function

[jovial torrent]

ah ok nice

i'll give you the code i've made if you want, i have a problem with some keys of the keyboard

idk why but there certains keys that activate randomly and there is one that's alway activated exept if i press on an other key (idk exactly wich one now)

[boreal light]

This part of program is referring from n0110, and I use the same parameters about FMC

[jovial torrent]

FMC?

[boreal light]

But I don't know why it cannot work on n0120

Or FSMC, the bus that controls the screen.

[jovial torrent]

ok

and your numwork have u3 or not?

[boreal light]

u3?

[jovial torrent]

or idk the name of the ship on the bottom that's not on mine

[boreal light]

I didn't completely understand. My n0110 and n0120 are second hand

[jovial torrent]

wait

[jovial torrent]

there

[boreal light]

I understand. There's no U3. But I soldered one to test SBU function

[jovial torrent]

ok

[boreal light]

This is the parameters I referred from. It should work on n0120, but didn't

[jovial torrent]

:/

[timber tundra]

seem to be cost cutting measure that work on the revision 4.19

[boreal light]

@timber tundra@jovial torrent

[jovial torrent]

yes?

[boreal light]

It works! I'm too exciting

[jovial torrent]

hoo

very nice

we can continue this evening (for me)

wait, you use hex

i use .bin files

[boreal light]

I tried on my n0120, the ID is still 0x4E4101

[jovial torrent]

so should it be the same screen?

[boreal light]

Using hex file, you do not need to enter start address

[jovial torrent]

ok

[boreal light]

ID may be different for different batches. Mine may be an early product

And I also tried normal st7789 screen, it is 0x858552, as written on datasheet

[jovial torrent]

what? but it's not the same

[boreal light]

I don't know the exact reason, maybe it is using extra screen in stock

Or maybe the original owner had changed the screen

[jovial torrent]

i'll try with mine

[jovial torrent]

i'm here

with the script how do i get the screen id ?

[boreal light]

Just using a serial port monitor

[jovial torrent]

with an st link ?

[boreal light]

The message transfer via USB port

[jovial torrent]

ok

[boreal light]

No, just USB

[jovial torrent]

wich baud rate ?

115200?

ah yea

0x4E4105

same

but now can you find the screen model with that or not ?

[boreal light]

That means we don't need to modify the part about screen

[jovial torrent]

we don't need to modify wich code ?

[boreal light]

Only gpio configuration shall be changed, command don't

[boreal light]

Wait, not 0x4e4101?

[jovial torrent]

So we'll not make burn in ?

ah

no

it's not the same xD

[boreal light]

Oh no

[jovial torrent]

yes, i was thinking the same thing

i think i have a new screen

it's one from 2022.12.08

[boreal light]

This is tricky now

Mine is 2018

[jovial torrent]

but how does the bootloader work with different screens ?

[boreal light]

Here is a function to read the ID

[jovial torrent]

😦

so can we know my screen model with the id ?

[boreal light]

Just do a whole research in the project, we will find where is different

[boreal light]

I have searched in network, didn't find anything

The only way is to ask the manufacturer

[boreal light]

But only limit difference, most of the command are the same

[jovial torrent]

yea but the gama settings are different

[jovial torrent]

and can we ?

[boreal light]

BTW, I also searched about LCD_ EXTC, pow_en, te, none of the code use these pins

[jovial torrent]

ok

[boreal light]

I failed. They may refuse to receive small costumer.

Or I was unlucky

[jovial torrent]

could i try ?

[boreal light]

Yes, maybe they will have different attitude

[jovial torrent]

it's with an email ?

[boreal light]

I didn't find their email, only store on Alibaba

https://qr.1688.com/s/jeSuvhVz CZ7608

[jovial torrent]

ok, where and what do i need to send ?

[boreal light]

[email protected]

I find the email

[jovial torrent]

ok

[boreal light]

Take a photo of screen, write like this: your company needs 10000 screens like this. First of all, you need a few samples to test.

Or, your screen is broken, ask one for fixing

And most importantly, the datasheet

[jovial torrent]

yea

[boreal light]

Just ask them to send datasheet firstly

[jovial torrent]

ok wait

[timber tundra]

we don't really need datasheet

Gamma values are setup by Numworks afaik

[boreal light]

But we still need to configure some special command from datasheet

If not datasheet, what should we ask them for?

[timber tundra]

not really, everything is already in epsilon code

[boreal light]

But this part is in epsilon-core, which is a private sub repository

[timber tundra]

epsilon 18 exist 🙂

or Omega/Upsilon

same thing

your screen should be fine for that

other will need more info, if you have a good base, put it on github, i'll try to contribute asap

[boreal light]

Then we can still use the code in Omega/uspilon

[timber tundra]

yes

[boreal light]

Now I'd like to change the subject a little bit. Do you know how to burn the system?

I used the script to split the dfu firmware into two parts, but after burning the internal flash, nothing was displayed on the screen. Do I need to burn external flash first?

[jovial torrent]

hmm

what do you want to do?

[boreal light]

I want to test if I haven't broke any part of calculator

[jovial torrent]

of the screen or the whole calculator?

[boreal light]

Especially the screen

[jovial torrent]

have you even enabled the backlight ?

[boreal light]

I used the official dfu firmware

[jovial torrent]

so, it shouldn't be broken ?

the numwork firmware?

[boreal light]

I hope, but failed

[boreal light]

Yes, Yaya sent the link at the beginning of this channel

[jovial torrent]

yaya?

[boreal light]

Yaya.Cout

[jovial torrent]

ah yea this one

do you have extracted the external and internal?

because me yes

[boreal light]

No, I forgot

[jovial torrent]

wait i'm searching it

here it is

wait

i think the internal is to big

i'll cut it

ah no i have it

this one

but do you have an st link?

because it will lock the calculator

[boreal light]

Thanks, these really help me a lot

[jovial torrent]

i've tried decompile it

[boreal light]

I have stlink, jlink, and rp2040

[jovial torrent]

that's what i'm with

i'll try search the screen id

[boreal light]

I may also test how to unlock n0120

[jovial torrent]

should be easy

just use stm32programmer

[zealous tree]

It is possible to prevent the lock

[jovial torrent]

how ?

[boreal light]

Try to right-click the function, and 'find all invokes'

[zealous tree]

I've never done it for N0120 but you can replace the locking bytes

[jovial torrent]

there is no result for the screen id

[zealous tree]

You can try to identify some functions and rename it.

[jovial torrent]

ik

[boreal light]

Searching constant may have no result, try to search the ID-reading function

[jovial torrent]

ik what's the main function

[boreal light]

I have heard this method, directly modify the bin file, but have to understand the machine code

[jovial torrent]

but i've tryed to modify "Numwork" string but it didn't worked

[boreal light]

panelIDIdentifier

[jovial torrent]

hm

so i need to find that ?

[zealous tree]

Don't forget that STM32 is little endian

You have to reverse bytes

[boreal light]

VSCode can find every place that calls this function

[jovial torrent]

ah, my external.bin file is empty

the one i've sent

[boreal light]

shift+f12

[jovial torrent]

panelIdentifier() ?

[boreal light]

Yes

[jovial torrent]

no where

i don't think that the decompiler can find that

it should need a special decompiler

[boreal light]

Let me try in my work space

[jovial torrent]

i used that: https://dogbolt.org

what's the rdp address of the stm32h725vet6?

here i think

chat gpt told me this

found this

at this line

[boreal light]

I misunderstand. I thought you want to find the screen ID

[jovial torrent]

yea but i didn't found it

so i try with the rdp address

[boreal light]

You can try boot_addr1 (but I don't know its hex value

This is what we use rp2040 to modify it

[jovial torrent]

if i set rdp to BB (read prot) how do i unlock it ?

a reset ?

[zealous tree]

calibration[] is at 0x9AE8

[boreal light]

First, we need to unprotect read and write permission, and then we need to prevent the program from modifying the boot_addr1.

[jovial torrent]

yea

[boreal light]

https://github.com/ErynGalen/nw-rpi-guide

[jovial torrent]

but just to try, how do i unlock a ship with rdp to BB

i don't think i need it

yea it was that

[jovial torrent]

that's rdp

[boreal light]

Just follow these steps, but implement them directly in the code without relying on openocd

[jovial torrent]

to unlock it?

don't need it

i've tried with read prot not ship prot

[boreal light]

Understand

[jovial torrent]

it's unlocked now

[boreal light]

But I didn't learn this part, so maybe I cannot give you useful advice

[jovial torrent]

to prevent the numwork from locking ?

[boreal light]

Yes, if succeed, we can prevent the calculator being locked

[jovial torrent]

the best way will be to find it in the bin file

but not the easiest way

[boreal light]

It maybe very hard, because you have to understand machine code

[jovial torrent]

yea :/

[zealous tree]

I have already did it but for N0115. That's not difficult you just have to find addresses and values in the reference manual

[jovial torrent]

but if we use the original firmware and modify the bin file "external.bin" it doesn't work because the bootloader have detected that there was a modification but how does it work ?

[zealous tree]

The bootloader doesn't detect changes

[jovial torrent]

yea but how

[zealous tree]

This is the bootloader that locks the calculator

[jovial torrent]

yea but i'm not talking about that now

[boreal light]

From my thinking, the bootloader only detect the external.bin, but don't detect itself

[jovial torrent]

no not that

if i just put the original bootloader

and try to modify the external.bin it doesn't work

Like changing Numwork -> Rumwork

[zealous tree]

Yes it's thanks to ED25519

[boreal light]

The bootloader do locking progress not external.bin

So we don't need to modify external

[jovial torrent]

yea

[boreal light]

So it can still run

[boreal light]

It is an encryption algorithm

I thought he is an engineer

[jovial torrent]

me ?

[boreal light]

I thought it's someone's nickname, but not

[jovial torrent]

ok

[jovial torrent]

i've found that

and 0x52002020 is for rdp and 0x52002044 is boot0 and boot1

yea!

in c it's that

now i can remove rdp lock

[jovial torrent]

hm, why can't i use my st link on my locked calculator (not the one i'm using to do the tests)

is it possible that epsilon disabled the access via an st link?

ok done

i've unlocked the calculator

[jovial torrent]

if i just remove those two it doesn't work (there's just a red led)

if someone want the decompiled files (it's not decompiled code directly it's a linear view export from binary ninja)

And here is the function that i think is locking the calculator

08004e70  uint32_t sub_8004e70(int32_t arg1, int32_t arg2)

int32_t var_4  {Frame offset -4}
int32_t arg1  {Register r0}
uint32_t result  {Register r0}
int32_t arg2  {Register r1}
int32_t lr  {Register lr}

08004e70  {
08004e70      int32_t lr;
08004e70      int32_t var_4 = lr;
08004e70      
08004e84      if (arg1 == ((uint32_t)sub_800026e(0x5200201c, 0xf, 8)))
08004e84      {
08004eba          uint32_t result = ((uint32_t)sub_800026e(0x52002038, 7, 0));
08004eba          
08004ebe          if (arg2 == result)
08004ec0              return result;
08004e84      }
08004e84      
08004e88      sub_8000f8c();
08004e9a      *(uint32_t*)0x52002020 = sub_8000254(0xf, 8, *(uint32_t*)0x52002020, arg1);
08004ea6      *(uint32_t*)0x5200203c = sub_8000254(7, 0, *(uint32_t*)0x5200203c, arg2);
08004eac      /* tailcall */
08004eac      return sub_8000fb4();
08004e70  }

what's wierd is that there is a return but it's not used (at least in the decompiled C file)

[boreal light]

Yes, as you can see in cubemx, if you don't configure swd port, you cannot use stlink for debug

[boreal light]

You cannot simply delete them, but you can change the process

[boreal light]

The return value is not used, this function is for lock OPTCR and all _PRG registers

And f8c is for unlock

My opinion is, send wrong key to OPTKEYER, then it cannot lock flash, nor change boot address

[jovial torrent]

i have used mode "under reset" to fix it

[jovial torrent]

i've successfully removed rdp lock

now i just need to remove the part that changes boot1

yes

done

no more lock

by removing the whole if statement here

and removing those two line here:
08004e9a *0x52002020 = sub_8000254(0xf, 8, *0x52002020, arg1)
08004ea6 *0x5200203c = sub_8000254(7, 0, *0x5200203c, arg2)

and here is the bootloader

[brisk galleon]

And you can run everything? Like upsilon, omega... ?

[jovial torrent]

no

[brisk galleon]

ah

why? what is the next step?

[jovial torrent]

it's just that we don't need an st link to unlock the stm32

[brisk galleon]

ah ok

[jovial torrent]

trying to remove that (the signature verification)

so that we can flash any external firmware

[rapid trench]

I don't know if the bootloader would support this case properly, for example I'm not sure that the bootloader check if the slot is valid before booting (in which case you would have to flash a firmware on slot A because it would need to try to boot the first valid slot)

[jovial torrent]

but the rescue screen is on the bootloader

[rapid trench]

There is also maybe a minimum Epsilon version check, I don't know how it works, maybe based on the KernelHeader or UserlandHeader (https://yaya-cout.github.io/Nwagyu/reference/firmware/addresses-structures.html#kernel-header)

[rapid trench]

The bootloader let you flash anything in external flash, but have checks before booting

[jovial torrent]

yea ik that

[rapid trench]

So if you want to boot anything, you need to disable the signature check and probably deal with the minimum version requirement

[jovial torrent]

yea

disable the signature check is what i'm trying to do

[jovial torrent]

the signature verification is just with an if statement ?

[rapid trench]

I don't know

[jovial torrent]

and is there a signature verification on epsilon 15 ?

[rapid trench]

Non

[jovial torrent]

ok

[zealous tree]

The check is at 0x08007fb8

[jovial torrent]

ah

it's just the break?

[zealous tree]

If you replace 0x00 by 0xE4 for example it should boot in any cases

[jovial torrent]

ok

i need to do that on the two cmp?

or just that one

[zealous tree]

The second cmp is for the slot B

[jovial torrent]

ok so i need to set it too to be able to use slot B

[boreal light]

It is a large function

[zealous tree]

This bootloader try to boot the slotA first so to disable the check fot the slot B is not very useful

[jovial torrent]

yea!!

working

tks!

but now technicly omega can be used ?

[boreal light]

Try upsilon or Omega?

[jovial torrent]

yey that what i'll try

[zealous tree]

Not on N0120

[jovial torrent]

or at least omega can be remaked for n120

because now the bootloader is 100% unlocked

[zealous tree]

Yes if we write the kernel

[zealous tree]

It was already the case but this bootloader is not practice and we don't have drivers

[jovial torrent]

the "epsilon-core" part

?

[boreal light]

Yes, that used to be lowest driver part

Like register address, configuration

Now it is private

[jovial torrent]

yea ik

[boreal light]

From what I am thinking, epsilon core is part of bootloader, not in main system

[jovial torrent]

that what i was thinking

[boreal light]

It should be able to run Omega without any modify of the main system

[sharp timber]

is this turning into "let's port omega/upsilon to N0120"

[jovial torrent]

yea

[sharp timber]

ayo 👀

[jovial torrent]

for now we could technicly modify the external.bin directly but it's a pain

we need to modify it with assembly

[timber tundra]

Lmao no

That's not how things work

[jovial torrent]

what ?

[timber tundra]

Shit idea

Sorry but that's not how it work

You really need to redo everything in the code, it's not a simple edit

[jovial torrent]

yea

[olive siren]

you managed to unlock your n0120?

[jovial torrent]

yea, but we can't make a custom external

we can only easly change strings

[olive siren]

why not?

[jovial torrent]

we don't have the driver that's on the external part :/

[olive siren]

but in principle it's unlocked and we could install anything on it (provided there's drivers)?

[jovial torrent]

yea

we can modify the .bin file

[olive siren]

does it need any additional hardware to do?

[jovial torrent]

just need an st link to unlock it if yours is locked, but most of the time it's not locked

[olive siren]

how could i know if its locked?

[jovial torrent]

i'll explain you in private

[olive siren]

alright

[boreal light]

Here is a little progress: I successfully boot 19.5.0 by prototype bootloader

Just move this interruption vectoer table to 0x0807fc00

However, it still cannot boot latest 23.2.5 system

BTW, the interruption vectoer table in n0110 and n0115 is located at 0x0800e000

[timber tundra]

You shouldn't use prototype bootloader, not a good reference

[boreal light]

Yes, but I cannot run n0120 on the prototype board, nor on my n0120 calculator. I don't know what's going wrong

[timber tundra]

Wdym

It should work on a retail one

[boreal light]

I follow RubyLava's method, unlock my n0120, but after flashing a modified bootloader, it didn't work. And even I flash the original bootloader, it still didn't work

[timber tundra]

You probably have to remove pcrop

That can be done from ST cube from the USB DFU

[boreal light]

I think I have removed the pcrop, is it right?

This is rubylava's setting, I copied this

[timber tundra]

I don't have the full specs in my head I'll need to have a look

[boreal light]

Great news, the prototype finally can boot latest version

If you change the PCB version (at 0x0807fa00) larger than 4.2.0, it will successfully boot

It seems like when the PCB version is lower than 4.2.0, the system will execute extra code, I'm going to find which part cause the crash

[brisk galleon]

and in the end, if we compare the external of the n0120/n0115 to that of the n0110, is it ultra different, or just a little?

[timber tundra]

it's not the same thing

it's just fitted for each hardware

[brisk galleon]

Like every time Numworks wants to make a change to the firmware, they do it 3 times?

[timber tundra]

That's how it work

3 different binaries

[brisk galleon]

wtf

but how do they get it to be exactly the same every time?

(the same result)

[timber tundra]

build variant based on the same source

[brisk galleon]

yeah so there're some common points?

when we talk about "external", it's the entiere os (from apps, to drivers...) right?

[timber tundra]

the software but HAL is way different

[brisk galleon]

okay I see

so, could we like, possibly, put upsilon/omega on n0115 one day, or is it just a dream?

[timber tundra]

already done

[brisk galleon]

wtf?

on n0115?

tell me more

[timber tundra]

it work

[brisk galleon]

who did that? when?

[timber tundra]

7 month ago

[brisk galleon]

how is it possible that i never heard about that?

[brisk galleon]

and so, is it easy to do so?

where did you got the information?

[timber tundra]

No that's why it wasn't released

too much issue like the new screens variant which aren't supported

[brisk galleon]

oh i see

was it on this discord, on ti planet?

[zealous tree]

#off-topic-fr message

[zealous tree]

Is it possible to see the source code?

[brisk galleon]

thanks, that's clearly impressive

[brisk galleon]

the source code of what?

do you wanna see all the hal modifications?

[zealous tree]

Yes

[brisk galleon]

@oak atlas (sorry for the ping, maybe you can talk about it), posted it in the thread, idk if he was the one who made it or simply reuploaded the picture, but, do you still have/know the modifications you made?

[oak atlas]

what modifications ?

[brisk galleon]

sorry, forgot to tell the context, we are talking about adding upsilon/omega to a n0115, and you posted this picture, 8 months ago:

[brisk galleon]

i don't understand, aren't the screens of the two models the same?

[oak atlas]

That's actually not my picture

[brisk galleon]

oh, do you know where you found it?

[oak atlas]

I don't remember sorry

[brisk galleon]

np, sorry for the trouble!

[oak atlas]

nevermind

[brisk galleon]

I searched a bit and it doesn't look like the image was on the internet, so alerymin probably got it in a private conversation or on a discord server

[timber tundra]

5 different variant

Shared with the N0120

[brisk galleon]

okay, I've looked and the image doesn't seem to be from this discord either, it might be tiplanet, I've searched a bit on it, but it doesn't look like it

[brisk galleon]

ah shit, and, what is different? because they have the same screen resolution

[timber tundra]

Lot of internal settings like Refresh rate for some

[brisk galleon]

ok I get it

but we could resolve these problems, nope?

[timber tundra]

Not open source

And I'd need a sample of each to test, and I don't have that

[zealous tree]

Can't we look in the official kernel?

With Ghidra

[brisk galleon]

We can, but:

• you can look at the kernel before the 16 version
• or a kernel in obfuscated and strange assembly

[timber tundra]

I already did but we need to guarantee the exactitude of the data or it could cause damages to the screens which we certainly don't want

[brisk galleon]

(I can make mistakes, sorry if that's the case)

[brisk galleon]

Oh yeah, I didn't think about that

So, in the end, it would be the same for the n0120, maybe if we make a lot of efforts, we could use omega/upsilon but there would still be too much issues to be really usable

[zealous tree]

So there is no solution?

[timber tundra]

Brick screens

Which isn't a solution

Same goes for N0120

[brisk galleon]

But how did the person in the photo do it?

[timber tundra]

Good screen

[boreal light]

He may use the n0110 screens (you can see the ID from source code). New screens must perform a gamma calibration, otherwise it may get glitch

However, if you modify n0115's bootloader directly, it may support all the screens

[brisk galleon]

incredible, how did you do for the screen?

[zealous tree]

I replaced send_command(Command::PixelFormatSet, 0x05); by send_command(Command::PixelFormatSet, 0x55);
It was the solution for my screen but as Rapid said do not reproduce this because if you don't have the same screen it can be very dangerous

[brisk galleon]

how can i know which screen i have?

[zealous tree]

I think the best would be to do it with a custom bootloader with the LED or the UART

[boreal light]

See the silk printing at the back of the screen

I also make a program to read out the screen ID

[zealous tree]

Oh yeah, I hadn't noticed that it was written

[brisk galleon]

oh i didn't know, thanks

[timber tundra]

I'm surprised this even work, it's not supposed to work like at all??

This required multiple changes around battery and USB to even boot, this just shows we can't really release anything considering the ton of hidden hardware changes

[zealous tree]

I had few issues with the battery level and reading the PCB version but the USB works fine

[timber tundra]

That's surprising, did you just bypass low battery level?

[zealous tree]

I lowered the minimum battery level but I wait until it is really low to see the minimum voltage

[timber tundra]

It's miscalculated on 115 because it use another offset

Use these

[zealous tree]

Thanks it works better

[tough mural]

Hello can someone explain to me where this arrived please ?

I am really interested

(Je parle français aussi)

[jovial torrent]

go private

[burnt zinc]

Juat curious, can this be tested on existing calculators?

Like if I have an n0120, could I test this out and if so what would need to be done?

[boreal light]

You need to unlock your calculator, then you can flash our modified bootloader

Although it can boot any customized system, there isn't any 3rd system for n0120 yet

[burnt zinc]

how would I do that

[tidal osprey]

c'est quoi le Hecxetdit?

[zealous tree]

Une application pour voir la mémoire de la flash et la ram

[tidal osprey]

merci

[boreal light]

You need a st-link to do that. Please DM me.

[devout nebula]

salut esque quelqun pourrait m'aider a installer epsilon sur ma calculatrice car j'ai un problome quand je vais sur le sit il detecte pas la version de ma calculette est sa frezze

[timber tundra]

[zealous tree]

Si tu parles bien d'espilon qui est le système officiel de Numworks ouvre un autre canal sinon tu ne peux pas

[uneven shadow]

@jovial torrent have you succeeded in flashing custom external flash?

On the n0120

I am trying to flash my own firmware that I built for the n0120

Modified version of epsilon

The bootloader rejects it

The thing is, the internal firmware does not even provide an svcall routine(it should, since kernel calls are done via this thing)

Is it implemented in the external one?

[rapid trench]

If you want some informations about the NumWorks, you can read that

https://yaya-cout.github.io/Nwagyu/reference/

[uneven shadow]

Still do not get it, there is no slot selection or sig verification in internal flash

It just sets up spi and clocks and some gpio basically the core layer to further jump to what is at 0x90000004

[uneven shadow]

@rapid trench ?

[timber tundra]

Nah it explicitly check for signature

Which is why you can only use 3rd party userland

What are the changes in your custom firmware?

[uneven shadow]

I just changed some strings from i18n

To test it out

[zealous tree]

What is the size of your internal.bin (without padding bytes)?

[uneven shadow]

328kb

Dumped it via stm32 cube

Didn’t let me read past 0x08050000

There were no calls out of the binary that I dumped

[zealous tree]

Without padding bytes it's too much. It should be about 40kb

[uneven shadow]

Maybe it has some padding, I am not sure

I am sure that I dumped all of what was accessible

[zealous tree]

But with padding it should be about 512kb

[uneven shadow]

That’s the thing

[uneven shadow]

Everything past this was not accessible

In any way

The utility just stuck

And the calc rebooted

[zealous tree]

With RDP1 we should not be able to dump

[uneven shadow]

That’s the thing

I can still read the first 0x50000 bytes

Idk how

[uneven shadow]

I thought it should’ve been like that

I mean based on what I dumped I guess we can reconstruct the boot sequence

Adapt the old bootloader

[zealous tree]

We can already download the bootloader from the numworks website

[uneven shadow]

That’s what I am talking about, why not just patch out the sigcheck and reflash the whole thing

[zealous tree]

It has already been done but it is not practical.

[zealous tree]

Just here

[uneven shadow]

Why not?

If you can but your custom os why isn’t it practical

[zealous tree]

But without drivers, you can't do much

[uneven shadow]

But isn’t epsilon made to run on that thing?

If I modify it I guess I will be fine

[rapid trench]

You can edit the binary, but the source code for the kernel isn't public (and we are wanting to edit the kernel, otherwise we would only use a custom userland) and redistribution is forbidden (copyright)

[zealous tree]

Epsilon is rather restricted

[uneven shadow]

So this is what I get:
I can modify the internal flash so that the bootloader boots in any cases.
I can wipe the internal flash(while setting RDP to 0) and reflash it with my own patched bootloader.
I can then reflash the userland to my own one without even touching the kernel

[rapid trench]

Yes, but the userland is still quite limited in terms of features

[uneven shadow]

Ah ok, I get u now

[uneven shadow]

Can you give me a link to the folder containing the kernel

In omega

[zealous tree]

Omega doesn't have a kernel like on epsion

You can go here in /kernel and /n0110/kernel https://github.com/numworks/epsilon/tree/version-18/ion/src/device

[uneven shadow]

Are they closing it because of the exam mode testrictionsv

?

[zealous tree]

Yes

[uneven shadow]

can I use the same unpack.py for epsilon 23 that is used to unpack the 18th one?

[zealous tree]

What do you want to unpack ?

[uneven shadow]

I want to somehow get and unpack the epsilon 23 .dfu file into external and internal flashes, modify the internal flash(the bootloader), and reflash my calc's bootloader with the new one

Is it possible via the stm32 cube via the DFU mode?

Or should I go and by an st-link adapter?

[zealous tree]

If it's for N0120 you can use this https://github.com/the6p4c/dfuse-extract

[uneven shadow]

Thanks!

[zealous tree]

You can use unpack.py but it requires some modifications

[uneven shadow]

And could you give some ideas on how to flash it please? Would be very helpful 🙂

[zealous tree]

I never did it on N0120 but RubyLava did it via stm32cube

Do you have an st-link or a raspberry pi ?

[uneven shadow]

Nope, none of them

[zealous tree]

We can't do it from USB

[uneven shadow]

Oh, ok..

But why not?

What exactly goes wrong?

[zealous tree]

We cannot change the option bytes otherwise the calculator would not be locked

[uneven shadow]

Have you tried checking this option?

I've seen a guy erase his internal flash while using this option so technically it should work

The one that is "Read Unprotect"

[zealous tree]

Are you sure ? Only from USB ?

[uneven shadow]

Yep

I've selected the usb mode up there

You can select between USB, UART, JTAG/SWD and the ST-Link one

That's how I dumped the internal flash🙂

[zealous tree]

Are you talking about the integrated dfu mode from the MCU ?

[uneven shadow]

The one that comes with the chip?

Yea

that thing that pops up when you resent while holding 6

You can then connect to the calc via usb

open up the stm cube

[zealous tree]

Not possible on a locked calculator and even more on a N0120

[uneven shadow]

enter the vid and pid and read memory

well...

I've managed to do so

[uneven shadow]

But the "lock" is basically in the softloader(numworks' dfu )

[zealous tree]

But what you dumped seems doesn't match with the internal flash

[uneven shadow]

I've opened it up in ghidra

Looks like a bootloader

maybe I skipped some functions

Ima check again now

[zealous tree]

Are these bytes are in your bootloader ? 14def9de

This is the beginning of a ED25519 constant

[uneven shadow]

You mean just search for them in ghidra>

?

[zealous tree]

yes

[uneven shadow]

at 0800a154

[uneven shadow]

this one

Btw, do you know any website where I can get the epsilon .dfu file?

Been searching and couldnt find it anywhere

I am sure I've seen it somewhere

[zealous tree]

https://my.numworks.com/firmwares/N0120/stable.dfu

[uneven shadow]

Oh, ok, there it is

Thanks!:))

[uneven shadow]

Yea I actually did

Just found the part where it selects the slots

And checks for the sigs

The binary is actually full of filler bytes, that's why it was so big

So, any ideas if it will work?

[zealous tree]

What ?

Erease the flash ?

[uneven shadow]

Flashing via usb

Yea

[zealous tree]

You can try but for me it is not possible

[uneven shadow]

With that one option toggled

[uneven shadow]

Even reading the memory?

[zealous tree]

I thought it was not possible but I never checked if RDP1 is enabled on N0120

[uneven shadow]

I guess it is not...

One more strange thing - the patch you showed me is not at the address that it was in the image

it is actually at 08008246

in my dump

I've opened up the epsilon 23 bootlaoder

one from the dfu file

everything is correct there

while in my dump, it is at a different address

not sure why

[zealous tree]

They sometimes change some little things in the bootloader but I don't know why

[uneven shadow]

I guess it just comes down to the compiler

It tends to put functions at arbitrary addresses

Unless you specify explicitly

By the way, another funny thing, stm cube just straight out crashes when I try to modify that one byte

It does when I try to modify anything

So I guess I will have to straight up reflash it...

[zealous tree]

What are you trying to modify ?

[uneven shadow]

In the memory view

One more thing, if I flash the one bootloader that I extracted from the .dfu file, will I be fine?

[zealous tree]

yes

[uneven shadow]

I am a bit hesitant because the addresses of the functions in the dumped one do not match what is in the one I downloaded

[zealous tree]

This is not surprising. They even change from one update to the next.

You can try with https://my.numworks.com/firmwares/N0120/beta.dfu it will be different again

[uneven shadow]

The extracted internal flash is like 523 kb long

this is even larger than the internal mcu flash size

@zealous tree @jovial torrent

@timber tundra @rapid trench any help?

Guys..?

[zealous tree]

From beta.dfu ?

[uneven shadow]

from the stable one

[zealous tree]

Not for me

[uneven shadow]

what do you mean?

[zealous tree]

When I extract stable.dfu I have 512kb

Ah you mean from the calculator ?

[uneven shadow]

nope, the one that is in stable.dfu

the bootloader

well that is a macos issue

not with the firmware

i am a bit afraid of checking that read unprotect optionf

[uneven shadow]

the only other way to reflash the mcu is to use the st-link?

[uneven shadow]

yep, I get the same

[zealous tree]

Yes or a Raspberry Pi but st-link is may be more practical

[uneven shadow]

i've selected the read unprotect option and the cube says "Device Read Unprotect requested" but nothing basically happens

[timber tundra]

that's normal, nothing is supposed to happen in that mode for quite obvious reasons

[uneven shadow]

can you explain?

i do not get it

if this is the flag to change rdp from 1 to 0, it should at least erase the bootloader

but I do not see anything happen past that message

[zealous tree]

But we're not supposed to be able to do like this

[uneven shadow]

only with st-link that this is possible?

and which one did you use?

[zealous tree]

I use a raspberry pi but any will do

[uneven shadow]

So you used the picoprobe for swd?

Or you somehow emulated stlink?

[zealous tree]

Yes picoprobe/debugprobe and OpenOCD

[uneven shadow]

Thx!

Has anybody already reverse-engineered the signature check for the external firmware>

And another question, if Numworks can upload their own internal and external flashes(that are signed) via DFU, why can't we do the same for an internal flash(bootloader) if it is not signature-checked?

[rapid trench]

Yes, it's known since even before Epsilon 16 was stable (bootloader wasn't even locking the calculator during the beta). The algorithm is ED25519 (based on libsodium IIRC) : https://tiplanet.org/forum/viewtopic.php?f=102&t=24973

Actually, I'm not sure about libsodium as I can't find it anywhere when search, on both Discord and TI-Planet

#dev-omega-fr message

It's libsodium, Discord search is really buggy

[uneven shadow]

Ok, but what about this thing?

Does the DFU interface check against the signatures?

Or it blindly puts in whatever is fed to it?

[timber tundra]

To answer quickly, no you won't be able to do anything via DFU

Internal can't be modified

External can be modified but need to be trusted by internal at boot time

[uneven shadow]

But somehow numworks can push both internal and external updates

via their website

@timber tundra

[timber tundra]

not internal

[uneven shadow]

then why does the .dfu package have the 0x08000000 section?

I guess that the whole .dfu file is pushed

[timber tundra]

that's not how things work

• pre-e16 calcs

[uneven shadow]

then why do they supply us with the firmware for the internal flash?

[timber tundra]

.

[uneven shadow]

what do you mean?

[timber tundra]

calcs that need to be updated to E16

[uneven shadow]

Ok, but can the userland overwrite the kernel header? Since it is in ram and probably persistent

Sorry, slot info

[rapid trench]

You can probably change the slot info, but why would you do so ? AFAICT, it's not used by the kernel, it's mostly used from a computer to know the current slot and by external apps. Upsilon bootloader had a bug causing slot info header magic to be corrupted on calculator suspend, and almost nobody noticied it (I discovered this bug when creating NWA apps)

[uneven shadow]

My hypothesis is, if you can swap the slot A kernel header pointer to the slot B one's, you can basically jump into slot B userland when the calc thinks it is booting up the A slot

[timber tundra]

that's actually the intended behavior of 3rd party userland system

use Kernel A to boot Userland B

[uneven shadow]

The think is that you make the slot A kernel header pointer point to the slot B’s kernel header

[rapid trench]

You can't jump this way. To cause a jump, you need to edit the program counter, by various means (explicit DFU jump, the official way to load a custom userland, or by exploiting any vulnerability in the userland like somehow modifying the return address in the stack)

The calculator can run perfectly fine without the slot info

[uneven shadow]

then is there any way to patch the bootloader with just software?

or, more generally, make the n0120 boot up my personal userland each time instead of the original epsilon even after a reset

[rapid trench]

Without hardware access, you can't change the bootloader, so it's not possible

[uneven shadow]

but what about this?

[timber tundra]

that's a security feature and we won't help bypass it because there is no reasons to make such an edit

[uneven shadow]

Hey, but isn’t the picoprobe a tool for probing another raspberry pico?

The debugprober uses a custom motherboard, not a regular raspberry pico

Could you please tell me which one did you use?

[zealous tree]

Not only

[zealous tree]

You can use both, the debugprobe is specialized for debugging (with connectors for example) but you won't really be able to use it for anything else (but in this case a stlink is perhaps more suitable)

[uneven shadow]

One more thing - in their documentation, they say I can install a custom userland(B slot). However, when I try to flash the calculator with the tool they have provided in their repo, it just resets and no custom userland is there. Neither can I install .nwa apps via their website - nothing appears to happen. Any info on why can this happen and is it a normal behaviour? (n0120)

[rapid trench]

Which Epsilon version do you have on your N0120 ?

Epsilon 19 doesn't support external apps or custom userland

[zealous tree]

And did you replaced n0110 by n0120 in the commands ?

[uneven shadow]

the 23rd one

[uneven shadow]

where exactly?

[zealous tree]

make clean if [ "$(python3 build/device/dfu.py -l | grep '0x90000000')" ]; then make userland.A.dfu; python3 build/device/dfu.py -s 0x90010000:leave -D output/release/device/n0110/userland/userland.A.dfu; else make userland.B.dfu; python3 build/device/dfu.py -s 0x90410000:leave -D output/release/device/n0110/userland/userland.B.dfu; fi;

[uneven shadow]

lemme see

[zealous tree]

In this command

[uneven shadow]

nope, but I dont see an option to choose the calc version to build for

in the makefile

[rapid trench]

There is no n0110, it's assumed to be the default

You can add MODEL=n0120 in the make commands

[zealous tree]

Ah yes indeed it's just on the file path

[uneven shadow]

yea, just built for 0120, still does not work:(

flashing for userland B

building epsilon@version-23

Well, apparently(not sure how), I have the KhiCas kernel installed at 0x90400000(there is a 'khi120b' string at this address). There was a time when I tried to install KhiCas but didn't manage to get it to work either. Neither do I know how did this(https://xcas.univ-grenoble-alpes.fr/nw/nws.html) website manage to flash the kernel. Any info?

[rapid trench]

It's not a kernel, just a binary launched by an external app

The whole external flash is freely read-write from a computer

[uneven shadow]

Then any clues on why can't I run the userland B after building for n0120?

and using their DFU tool to flash it

[timber tundra]

please open a new help topic + you need to have latest epsilon on both slot and update via recovery per 6 +reset on Numworks website

[uneven shadow]

Hey, just bought a pico, what were the pads you connected your probe to on the calculator?

i see the vref/rx/tx but these are apparently for uart

don't see any of swd pads

[uneven shadow]

So I have managed to connect to the chip via openocd, but after "Info : SWD DPIDR 0x6ba02477" i instantly get
"Warn : target stm32h7x.cpu0 examination failed". Openocd commands like "reset", "reset halt" fail with "Target not examined yet"

any clue on why this may happen and if it should be like that?

[uneven shadow]

@zealous tree @jovial torrent

[zealous tree]

What command did you use ?

[uneven shadow]

openocd -f "custom_config.cfg"

custom_config.cfg:

interface cmsis-dap
transport select swd
adapter speed 1000

source [find target/stm32h7x.cfg]

so?

Ran on windows

Flashed the drivers with zadig

Libusb latest

[zealous tree]

Did you do from reset+6 ?

[uneven shadow]

Built the debug probe from source with debug_on_pico=on

[uneven shadow]

Yep

Any clues?

[zealous tree]

try with adapter speed 5000

[uneven shadow]

Do
You think adapter speed can influence this?

[zealous tree]

it is possible

did it work?

[uneven shadow]

Haven’t tried it yet

Will check tomorrow

But thanks in advance!

[zealous tree]

finally I don't think

[uneven shadow]

yea so apparently speed 5000 doesn't help

openocd says that "CMSIS-DAP Protocol Error @ 3 (wrong parity)"

and right after that:
Debug: 156 1084 target.c:1846 target_call_event_callbacks(): target event 20 (examine-fail) for core stm32h7x.cpu0
Warn : 157 1091 target.c:795 target_examine(): target stm32h7x.cpu0 examination failed

[uneven shadow]

The problem was loose connections to the motherboard 🙂

But now, after running "stm32h7x unlock 0", I try to execute "stm32h7x mass_erase 0", but this gives me an error "wait_flash_op_queue, WRPERR detected"

[uneven shadow]

@zealous tree @jovial torrent

[uneven shadow]

Nvm guys, managed to solve it

for anyone facing the same issue, check the stm32h7 reference manual page 167, "flash bank erase with automatic protection-removal sequence"

[uneven shadow]

well the problem after flashing now is that the inputs do not work

like the keyboard, the USB port

[uneven shadow]

Epsilon boots up fine

But I can’t interact with it

Neither can I enter the bootloader

Flashed it with the flash I got from the numworks website

And modifier the check for the slot A

How @zealous tree mentioned

And I can’t get my picoprobe to connect to the mcu

so apparently the only thing that is not working is the keyboard

I am not sure why

[uneven shadow]

trying to enter the recovery by connecting boot0 pad to the 3.3v pad, no success (

[zealous tree]

The BOOT0 address was changed by Numworks

[uneven shadow]

and do you know how do I enter it now?

what's interesting is that the keys are working when I connect to the computer and the USB screen pops up

I can press the back key and it will exit the screen

but after that the calc just stops responding to the keyboard

any clues?

@zealous tree

[zealous tree]

It hasn't worked since you flashed the bootloader ?

[uneven shadow]

yep, the first thing I noticed is that I could no longer get into the recovery by holding 6+reset

as it further turned out, all the keys stopped working

I can still connect to the stm32cube via the usb

and I can even exit the USB popup screen by pressing that back arrow key

but apparently that's the only key that works

and I do not know why

[zealous tree]

How did you flash ?

[uneven shadow]

flash write_image erase internal.bin 0x08000000 bin

after the mass erase

[zealous tree]

Did you try to reset with the reset button ?

[uneven shadow]

yes, but it didnt help

tried just now

the thing you said about boot0

what did you mean by "they've changed the address"

[zealous tree]

Now the boot0 boot from internal flash and not from the embedded bootloader

[uneven shadow]

if I connect the boot0 pad to the 3.3v I should still get into the bootloader?

am I right?

the one that is in the flash

[zealous tree]

yes Numworks Bootloader

[uneven shadow]

But I don’t think it works because whenever I try to connect the two pads nothing basically happens

Using this jumper wire

[zealous tree]

You have to reset while doing that

[uneven shadow]

I dont think i can get it

i am resetting

while the cable is connected to boot0 and 3.3v/vbat(tried both)

but still, the calc loads up epsilon

i will try with a shorter wire

maybe the resistance is too big

[zealous tree]

try only 3.3V

[uneven shadow]

nope, nothing

boots up like normal

I can’t get swd when the OS is running

I've tried to connect with openocd right the instant i reset the mcu

it actually find the mcu

but then tells me that it couldn't examine the chip

that's weird

and the led just turns red

[zealous tree]

Yes it's normal

[uneven shadow]

but why can't openocd examine the mcu then?

if it is connected

[zealous tree]

How did you reset ?

[uneven shadow]

pressed on the pad

and the instant i did it I ran openocd

at first it seemed to have connected

printed out info about the mcu

but then failed to examine

Smth like this

The led just stays red

@zealous tree

[zealous tree]

When you have this message is the calculator on black screen and red LED ?

[uneven shadow]

Apparently I can get it to connect

[uneven shadow]

This time I didn’t halt and reset it

And it connected

But after a successful “reset halt” it turns red and unresponsive

That’s the thing

I’m not sure what I do now

Like why could the keyboard work only for the USB screen

And not even for the bootloader

Maybe I should have flashed the bootloader I dumped and not the one that comes with the DFU file?

From the numworks website

[zealous tree]

What is the size of the bootloader that you flashed ?

[uneven shadow]

12kb

512

kb

511.1

to be exact

[zealous tree]

And the SHA256 checksum ?

[uneven shadow]

hm

lemme see

[pure dew]

Do you managed to run Omega/Upsilon on N0115 and N0120?

[uneven shadow]

of the unmodified?

the one that I extracted?

from the .dfu

[zealous tree]

Only N0115

[pure dew]

that's a beginning

[zealous tree]

The internal that you flashed

[pure dew]

and does it need to do stuff on the hardware or can it be achieved only using USB ?

[zealous tree]

With a raspberry pi

[pure dew]

so you have to connect wires on the mainboard?

[zealous tree]

yes

[pure dew]

ok, that's not the easiest way to crack the calculator but It promising

And do you think it could be possible only with USB ?

or it will require to find a hack in the firmware?

[zealous tree]

Not in USB but it is unlikely that there is a software flaw

[uneven shadow]

67b2abff7f6c1d2be0958bbbb511e927c4ba5a07bfe8cc45b375d2ef388d1f5c

[pure dew]

pourquoi le post a commencé en français et a dérivé vers l'anglais ? 😆

[zealous tree]

Is it the bootloader of epsilon 23.2.6 stable for N0120 ?

[uneven shadow]

yes

yes it is modified

replaced 00 with e4 as you said

[zealous tree]

The unmodified should be 945207bccd06929937359f4b62ca0a117d4a580fee3a9704eb8f92d025b265c2

[uneven shadow]

945207bccd06929937359f4b62ca0a117d4a580fee3a9704eb8f92d025b265c2

this is unmodified

yea matches

[zealous tree]

So this seems to be the good bootloader

[uneven shadow]

so should I flash the original bootloader?

[zealous tree]

It shouldn't change much

[uneven shadow]

then where can the problem come from?

btw

I tried flashing both slots from dfu

built the userland.A.dfu and userland.B.dfu and flashed the corresponding slots

but it didnt change anything

seems like i cant even flash it using dfu

i changed some strings in epsilon

but nothing changed after flashing

[zealous tree]

which ones ?

[uneven shadow]

i18n in the usb app

"THE DEVICE IS CONNECTED" to "HELLO WORLD"

[uneven shadow]

i wanted to flash the old bootloader that I previously dumped, to see if it was the cause, but now that I had erased the flash, I can no longer connect to the MCU with openocd (i mean, it sees the IDR register - 0x6ba02477), but says that it couldn't examine the target: "Warn : target stm32h7x.cpu0 examination failed"

When I make the log more verbose, it says that there was an error in the protocol: "Debug: 156 958 cmsis_dap.c:880 cmsis_dap_swd_read_process(): CMSIS-DAP Protocol Error @ 3 (wrong parity)"

I have soldered the swdio/swdclk wires to the pads

@zealous tree

[zealous tree]

You have only black screen and red led ?

[uneven shadow]

yep

[zealous tree]

Is it detected when you plug in via USB ?

[uneven shadow]

yes

[zealous tree]

As STM32 Bootloader ?

[uneven shadow]

you mean if I pull boot0?

[zealous tree]

no just when you plug in

[uneven shadow]

I just plug it in and I see a red light

nothing on the screem

and I get this when I try to connect to the chip

[zealous tree]

So if you click on connect on this site with the calculator connected you don't see anything? https://ti-planet.github.io/webdfu_numworks/n0110/

[uneven shadow]

nope, dont see any devices

got any clues?

[zealous tree]

What happen when you try this ?
program internal.bin 0x08000000 verify reset exit

[uneven shadow]

Info : SWD DPIDR 0x6ba02477
Info : SWD DPIDR 0x6ba02477
Error: Target not examined, will not halt after reset!
** Unable to reset target **
shutdown command invoked

[zealous tree]

So I guess it's the same with init; reset halt; program internal.bin 0x08000000 verify exit

[uneven shadow]

init
reset halt
SWD DPIDR 0x6ba02477
SWD DPIDR 0x6ba02477
Target not examined, reset NOT asserted!

program internal.bin 0x08000000 verify reset
SWD DPIDR 0x6ba02477
SWD DPIDR 0x6ba02477
Target not examined, reset NOT asserted!
embedded:startup.tcl:1029: Error: ** Unable to reset target **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 1066
at file "embedded:startup.tcl", line 1029

Soooo did I brick it?

[zealous tree]

Hmm I don't know. I'm trying to figure out why SWD isn't working.

It should work

[uneven shadow]

It says it has that weird “wrong parity” error