13:30 <larsc> Hm, is there like a special name for non-leaf nodes in a graph?

13:31 <ysionneau> "root of a subtree" ? :p

13:39 <wpwrak> inner/internal nodes ?

13:40 <zcrc> intermediate nodes?

13:41 <zcrc> (if your graph models a path)

13:41 <wpwrak> the consensus seems to be "in* nodes" :)

13:43 <zrafa> wpwrak: some status with little board: I did some flash using ben.c libswd.c into mk26. I used ben.c, flashed and then the mcu did not talk with me anymore ( I do not get any answer now, neither I get the ID from mcu :( ). I seems to me like to flash incorrect firmware could hurt right?

13:45 <wpwrak> hmm yes, it could (if you activate code protection in an particularly bad way). but ... you should still be able to establish basic SWD communication.

13:46 <wpwrak> is that a board with more capacitors or still your first version ?

13:48 <zrafa> the first versionyet

13:49 <zrafa> but no more basic swd communication

13:51 <larsc> inner nodes sounds good, thanks

14:21 <wpwrak> zrafa: hmm, maybe your code causes the device to draw a lot of current and this then crashes the chip, due to insufficient buffering. that could explain such issues.

14:22 <wpwrak> you may also want to check your cables. you wouldn't be the first to spend days searching for a software problem when in truth it's a broken connection ;-)

14:26 <wpwrak> to work around supply problems, maybe increase the duration of reset before trying to talk via SWD. (right now, there's no delay there)

14:59 <zrafa> wpwrak: I will check, thanks a lot.

15:00 <DocScrutinizer05> particularly for flashing the power supply has to be flawless

15:00 <DocScrutinizer05> page erase seems to be power hungry

15:01 <wpwrak> DocScrutinizer05: "should". i'm surprised with what sort of atrocities you can usually get away with ;-)

15:01 <wpwrak> but yes, if your power is crappy AND you experience problems, there's your #1 suspect

15:01 <DocScrutinizer05> not with a failed page erase

15:02 <DocScrutinizer05> aiui the ROMBOOT or whatever it's called should kick in first nevertheless, no?

15:04 <DocScrutinizer05> IOW even with a bogus content of flash stroage, the communication to device should still work for the initial unbrickable ROMBL based part

15:04 <wpwrak> i'm not even sure there's much of a ROM in these chips. but there's something better: the ARM SWD hardware. that should work no matter what else the CPU is doing. well, except if the reset pin is configured as I/O.

15:05 <DocScrutinizer05> *shrug*

15:08 <wpwrak> there are basically two ways to "brick" that chip: a) lock the flash and disallow mass erase. that will prevent any alteration of the flash. that is, unless you've set a "backdoor key" or you're freescale and the user has not disabled freescale's backdoor key (or maybe freescale have a 2nd key you can't disable, then you'd have to be able to terrorize them into applying that or giving it to you)

15:10 <wpwrak> 2) disable the reset pin by clearing a specific bit in the Flash. that should also prevent SWD from being accessible.

15:16 <wpwrak> (but i could be wrong on that ... documentation isn't entirely unambiguous on this issue)

16:44 <wpwrak> zrafa: https://community.freescale.com/message/380989#380989 "Note that it is important to have the power supply capacitors otherwise the device programs erratically." :)

16:47 <wpwrak> you may want to check nRESET with a scope. if you can see that 125 kHz pattern, the chip is looping through reset

17:11 <DocScrutinizer05> toldya

17:26 <DocScrutinizer05> moo dos1 err DocScrutinizer05

17:41 <DocScrutinizer05> qi-bot: 1+1

18:25 <dos1> DocScrutinizer05: sup?

18:25 <DocScrutinizer05> fine weather

18:25 <DocScrutinizer05> and Tim riker fixing another bug in bot I spotted

18:26 <DocScrutinizer05> (you might have noticed bot leaving&joining a few times)

18:27 <DocScrutinizer05> mc "fixed" on fremantle extras

18:27 <DocScrutinizer05> municipal agencies slow as usual

18:28 <DocScrutinizer05> Ukraine conflict worse than yesterday, as usual

18:30 <DocScrutinizer05> (perceived) health also worse than yesterday, as usual

22:33 <qwebirc8594> Wondering if the Neo900 or whatever it is called has gone missing? or project is simply VERY stalled. I hope it happens, however.

22:35 <whitequark> on schedule so far; nothing was promised until the autumn afaik

22:35 <qwebirc8594> thx whitequark this is rjeffries too lazy to issue a /Nick command LOL