Hi!


I'd like to make a Ndless program able to control the LED present on the following models:
* TI-Nspire ClickPad
* TI-Nspire TouchPad
* TI-Nspire CAS TouchPad
(the TI-Nspire CAS ClickPad doesn't have that LED but has the circuit -> you might make a hole and solder it)

There are many uses for that LED.
It could be used in games as a won/lost or hit/missed indicator.
You might use it to indicate your mood of the day: red for "mad: don't speak to me today", yellow for "I'm in love", for example...
We might use it to communicate short answers: yes/no, little number...
We could also use it to communicate fully by using some king of Morse code.


The LED is documented on HackSpire and it looks quite easy:

90110000 - LED

    * 90110B00 (R/W): Control register
          o Bit 0: Set this bit to enable green light blink data. If green blink data iteration is not on, the green light state is read from bit 0 of green blink data.
          o Bit 1: Set this bit and bit 6 to enable green blink data iteration.
          o Bit 2: Set this bit to force green light off. Overrides bit 4.
          o Bit 3: Set this bit to force red light off. Overrides bits 5 and 13.
          o Bit 4: Set this bit to force green light on.
          o Bit 5: Set this bit to force red light on.
          o Bit 6: See this bit and bit 1 to enable green blink data iteration. Reset before modifying green blink data or delay.
          o Bit 9: Set this bit to enable red light blink data. If red blink data iteration is not on, the red light state is read from bit 0 of red blink data.
          o Bit 10: Set this bit and bit 12 to enable red blink data iteration.
          o Bit 12: Set this bit and bit 10 to enable red blink data iteration. Reset before modifying red blink data or delay.
          o Bit 13: Forces red light on if bit 4 is 0, or red light off if bit 4 is 1. (?)
    * 90110B04 (R/W): Green blink data. 32 bits of on and off state, represented by 1 and 0. Iteration is done from bit 31 to bit 0 repeatedly.
    * 90110B08 (R/W): Green blink delay (negative). OS sets this to -2048.
    * 90110B0C (R/W): Red blink data. 32 bits of on and off state, represented by 1 and 0. Iteration is done from bit 31 to bit 0 repeatedly.
    * 90110B10 (R/W): Red blink delay (negative). OS sets this to -2048.

Note: If red and green lights are on at the same time, the color becomes yellow.

I've made a simple program.

#include <os.h>
#include "console.h"
#include "screen.h"
#include "charmap.h"
#define LED_MODE_ADDR 0x90110B00

int getMem(int addr)
{ return *(volatile unsigned*) addr;
}

void setMem(int addr, int val)
{ *(volatile unsigned*) addr = val;
}

int main(int argc, char* argv[])
{ int mode_orig = getMem(LED_MODE_ADDR);
int mode_base = mode_orig&~0b01011001111111; //turn OFF + disable blink / iteration / force on-off
clrScr();
int mode_curr=mode_base;
int mode_last=mode_orig;
while(!isKeyPressed(KEY_NSPIRE_ESC))
{ mode_curr=mode_base;
if(isKeyPressed(KEY_NSPIRE_R) || isKeyPressed(KEY_NSPIRE_J) || isKeyPressed(KEY_NSPIRE_Y))
mode_curr |= 0b100000; // force RED on
if(isKeyPressed(KEY_NSPIRE_V) || isKeyPressed(KEY_NSPIRE_G) || isKeyPressed(KEY_NSPIRE_J) || isKeyPressed(KEY_NSPIRE_Y))
mode_curr |= 0b010000; // force GREEN on
if(mode_curr!=mode_last)
{ setMem(LED_MODE_ADDR,mode_curr);
mode_last = mode_curr;

disp("Written LED mode: ",0);
dispi(mode_curr,0);
displn("",0);

disp("Current LED mode: ",0);
dispi(getMem(LED_MODE_ADDR),0);
displn("",0);
}
}
setMem(LED_MODE_ADDR,mode_orig); // reset
return 0;
}
You need to press some keys to turn on the red or green colors.


And I'm getting very strange behaviours.

I've tested on 3 TI-Nspire ClickPad and 1 Ti-Nspire TouchPad.
On 2 of them, it worked the 1st time, but that's all... It never worked again!!!
On the 2 others, it never worked.

The LED just remains off...

Strangely, I've experienced many reboots, either when entering the program, either after exiting the program...
Very strange as I don't use any other pointer than the 0x90110B00 address. And it did reboot before I added the debug display.


Here's a sample log of the debug informations displayed on the screen (when it doesn't reboot):

Written LED mode: 0 // 1st loop
Current LED mode: 5699
Written LED mode: 32 // press 'R' key
Current LED mode: 5699
Written LED mode: 0 // release 'R' key
Current LED mode: 5699

You see?
I'm checking the LED mode just after writing it.
And it's allways 5699!
My values aren't written, or are modified immediatly...

How is this possible? I thought interrupts were disabled while running a Ndless program...


The fact that it worked 2 times (with dozens of tries) this evening, proves that this address is read/write, as stated on HackSpire.

But there seems to be some kind of checking/protection, whose reliability is strong, but not 100%.


Can you help me?
Do you have any idea what is going on?
Do you see some stupid things in my code?

Thanks.


Please find attached the last binary.

If you want to modify & recompile, you just have to get "screen.*", "console.*" and "charmap.h" files in the mViewer archive, and use them with the code above.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014

I remember I had trouble with the LED light when I added it to Block Dude

Interestingly, I have never been able to get the LED to light in an Ndless 1.7 program, although it always works perfectly with Ndless 1.1 stuff.

For setting it, I used this routine (by calc84, I think):
set_led(int color) {
*(volatile unsigned*) 0x90110B00=color<<4;
}

As for the crashing, I found that when I used the nspire-ld flag "-nostdlib," the program crashed on me every so often (like what happened to you, it would work sometimes, but crash others).  When I removed the flag, everything worked fine.  I am not sure if this is what was causing the problem, but it fixed it for me!

I might be completly wrong, but I think that the calculator reboots beacause something related to PTT is triggered. (the calculator reboots both when entering and exiting PTT)

But my calculators aren't in PTT mode.
But maybe the reboots did activated some "lock led state" code related to PTT, without entering PTT... Would mean I would be in some king of "incomplete" PTT.

But I cannot reset that "special" mode without exiting PTT.. And I cannot exit PTT because I'm not in PTT... So, let's put the calculator in PTT!
(don't do it, unless you have a second TI-Nspire to unlock it)

I've taken 2 TI-Nspire ClickPad.
I've put them in PTT mode, and then I've exited that mode.
(thinking it could reset the "lock led" or whatever it is)

On one calculator:
* Immediate reboot when starting program.
* After that, same behavior as described above: memory content is not changed.

On the other calculator:
* It works! I press 'G', 'R', 'Y' keys, and the LED is turned on in green, red or yellow.
* I even managed to launch the program severall times.


It seems to confirme my hypothesis.
Now the question is: "how could I prevent rebooting while reading/writing the LED mode?"...

(don't do it, unless you have a second TI-Nspire to unlock it)

You actually don't need an other Nspire to exit PPT, you can also unlock it with a PC.
If you send a file with the name "Exit Test Mode.tns" in the "Press-to-test" directory of your calc, he reboots like if you did it the ~normal~ way.

I'm curious what would happen if you run your program during PPT (if Ndless works in PPT), I would test it myself but I have a touchpad cas... so no Ndless.

Nice Critor! Good luck trying to get it to work all the time.

I could be completly wrong, but the DEL locking could have something to do with boot2 1.4 (or with boot2 1.4 + OS 1.7).

The calculator which is working the best currently has boot2 1.1 + OS 1.7.
Itmight be totally unrelated though.

I'll make further tests later.
Currently, i'm developping the encoder(automatic)/decoder(manual).

Ah I see. I take it that they would get mad if someone messed with PTT and got it disabled, as it could get the calcs banned from school?

My program is not able to disable PTT.
It's not intended for that.

It's only intended to turn the DEL on/off.


But TI could get mad:
- if such program was used to fake a PTT mode
- if such program was used to exchanges informations (which is the goal here) during exams


Here is the Norse code:

no      R
yes      G
e      Y
s      RR
a      RG
i      RY
t      RR
n      GG
r      GY
u      GR
l      YG
o      YY
d      RRR
c      RRG
p      RRY
m      RRR
v      RGG
q      RGY
f      RGR
b      RYG
g      RYY
h      RYR
j      GRG
x      GRY
y      GRR
z      GGG
w      GGY
k      GGR
0      GYG
1      GYY
2      GYR
3      YRG
4      YRY
5      YRR
6      YGG
7      YGY
8      YGR
9      YYG
repeat   YYY

For example, 'Q' is indicated by flashing the DEL successively in Red, Green, Yellow, and then by a pause.

Indicative delays:

- DEL on: 300ms
- DEL off between 2 signals: 100ms
- DEL off between 2 letters: 600ms
(may still be changed)

Speed: 2.5 signals per seconds
Character encoding: 1 to 3 signals

Which mean 1s to 2.2s per character.

I can make this much faster, but I don't think your eyes will be ok with that.


The "HELLO WORLD" string needs 17secs to be sent.
The interface lets you repeat the message before entering a new one, if you think the recipient has missed some part of the message.
You've got a "sending" progress in percents too.

I've added a self-test mode in the program, which should let you figure out if the LED is locked or not.
I've finished the encoder.
Just the decoder is missing.

I've made further tests for the DEL with the following 4 calculators:
- 1x basic TI-Nspire ClickPad with Boot2 1.1 and OS 1.7
- 2x basic TI-Nspire ClickPad with Boot2 1.4 and OS 1.7
- 1x basic TI-Nspire TouchPad with Boot2 1.4 and OS 1.7


On the Boot2 1.1 calculator, no problem. The DEL is unlocked & working and the calculator is not rebooting.

On all 3 Boot2 1.4 calculators, if the DEL is unlocked, the program may trigger a reboot. It might happen when entering the program, or even severall minutes after exiting the program.
After this reboot, the DEL is locked. Writes to its memory port are just ignored and the DEL remains off whatever you do. Turning off/on or rebooting doesn't change anything.
The only way to unlock the DEL up to now is to enter and exit PTT mode. Just after the "exit" reboot, the DEL is unlocked.

This has even worked on the TouchPad.


Note I could be totally wrong, because I've only tested on 4 calculators, and only 1 "boot2 1.1" calculator.
I've attached an alpha binary if you want to try and help me.

Choose '4' to trigger my self-test.
If the last line has the "error" word, then your calculator LED is locked.
if not, it should be turned on by pressing G/Y/R keys.

I'd like to know for each calculator:
* which boot2 version you have
* what was the LED state on the 1st try: lock or unlocked (or reboot before knowing)
* how often it did reboot for you (if it does reboot)
* if you were able to unlock the led (if necessary) by entering and exiting PTT


Have fun turning your LED on/off and sending light-messages with your TI-Nspire.
(remembers me of my HP-48GX which had an I/R port to exchange data... but it was much faster! :p )


It would be interesting to make further test with boot2 1.4 calculators:
* checking if removing and reinstalling OS 1.7 does unlock the DEL
* checking if formatting the FS does unlock the DEL
* checking if the same "reboots" do happen on previous Ndless supported OSes (1.1, 1.3, 1.4)


Edit: further tests done:

* Basic TI-Nspire touchPad with boot2 1.4:
Triggering a 2nd reboot yourself after exiting PTT whith an unlocked DEL (after running the program, without having run the program, or even without having installed Ndless) does lock the DEL. Seems the DEL is locked by the Boot2 1.4 and/or the OS 1.7 at boot time, except with the "exit PTT" reboot.